Spell checker in Ax

There is a class in AX that allows to perform spell checking. This class uses Microsoft Word spell checker to do the validation. So, in order to use it, Microsoft Word should be installed together with proofing language pack. Because of this requirement it is also important to consider where to run spell checking - on the server or on the client.

public static server void spellCheckerTest()
{
SysSpellChecker sp = SysSpellChecker::newLanguageId('en-us');
;

info(strfmt('%1', sp.checkSpelling("behavior")));
info(strfmt('%1', sp.checkSpelling("behaviour")));
}


The output in infolog will be as below :-
1
0

Identical AX 2009 AUC File Created For Multiple AX Installations

We came across an issue recently where we had the same GUID for two different AX installations running on the same server and therefore only one AUC file existed for both installations instead of two separate ones for use by the AX Client.
This caused various anomalies when the client was used to access both instances. We expect each of the AX installations having their own separate objects and application files associated to the AUC file.

In order to ensure that a unique AUC file is created per instance for the AX client to use, and also to ensure that the AX instances had a unique Global GUID, the solution was to delete the GlobalGUID from the SysSQMSettings table in one of the instances and replace the value with an empty GUID (00000000-0000-0000-0000-000000000000).
Then restart the AOS service, as this will then generate a new GUID and allows a new AUC file to be created for the AX client when it is next run.

The above problem was most likely caused by using a copy of the same database.

The GUID is stored in the SysSQMSettings table and is unique for each AX installation.
You can find it by using the following Select statement:

" select GlobalGUID from SysSQMSettings ".. even you can have a look for the below job as well which will give you GUID and recId.

static void getGUID(Args _args)
{
SysSQMSettings SysSQMSettings;
;
select GlobalGUID from SysSQMSettings;

info(strfmt('%1, & rec id is -- %2', SysSQMSettings.GlobalGUID, SysSQMSettings.RecId));

}

Ax session issue in Axapta

Some Axapta system administrator may feel it is really annoying that Axapta allows the user to create multiple Axapta sessions and log in as the same user. If you want to give the user notification prior to logging in as the same User ID, see the below code. Under the Info class, modified the startupPost method something like below:

void startupPost()
{
int counter;
int num = 0;
int maxSessions = Info::licensedUsersTotal();
xSession session;
UserInfo userInfo;
UserId currentUserId;
;

currentUserId = curuserid();
for(counter = 1; counter < maxSessions;counter++ )
{
session = new xSession(counter, true);
if(session && session.userId())
{
select firstOnly userInfo where userInfo.id == session.userId();
if (userInfo && (currentUserId == session.userId()))
{
num++ ;
}
}
}
if (num > 1)
{
if(box::yesno("The same user id can't log in twice. Do you want to log in anyway? ", DialogButton::Yes, "Log in", "Log out") == DialogButton::No)

{
infolog.shutDown(true);
}
}
}

Code snipet 2 remove the identical copy of AOT object

For some unknown reasons, sometimes AOT objects are touched in VAR layer but actually are identical copies. When the developer compared the VAR layer object with the one in lower layer (BUS, SYS etc.), AX showed it was an identical copy and no difference as such.

Below is the code example on how can we remove the identical copy in X++ code:

static void FindAndDeleteIdenticalObjects(Args _args)
{
SysTreeNode comparable1, comparable2;
TreeNode curLevelTreeNode, upperLevelTreeNode;
UtilIdElements utilElements, joinUtilElements;
;
while select UtilElements where UtilElements.utilLevel == UtilEntryLevel::var && ( UtilElements.recordType == UtilElementType::Form Utilelements.recordType == UtilElementType::Report Utilelements.recordType == UtilElementType::Table Utilelements.recordType == UtilElementType::Class Utilelements.recordType == UtilElementType::Enum Utilelements.recordType == UtilElementType::ExtendedType
)

{
//Should use join if for a normal table, but not applicable for UtilElements
//Performance hit if use exists join
select firstonly recid from joinUtilElements
where joinUtilElements.utilLevel != UtilElements.utilLevel && joinUtilElements.name == UtilElements.name && joinUtilElements.recordType == UtilElements.recordType;

if (joinUtilElements.RecId)
{
curLevelTreeNode = SysTreeNode::findNodeInLayer(UtilElements.recordType, UtilElements.name, UtilElements.parentId, UtilElements.utilLevel);

upperLevelTreeNode = SysTreeNode::getLayeredNode(curLevelTreenode, 1);
comparable1 = SysTreeNode::newTreeNode(curLevelTreeNode); comparable2 = SysTreeNode::newTreeNode(upperLevelTreeNode);

if (SysCompare::silentCompare(comparable1, comparable2))
{
info(strFmt("Element name: %1, Element type: %2", UtilElements.name, enum2str(UtilElements.recordType)));
//Remove the node
curLevelTreeNode.AOTdelete();
}
}
}
}

It's a bit cumbersome here while pasting, but i think its gives an overview to understand the fact :)

Revised layer version in DAX 2009

In Microsoft Dynamics AX, a layer system is used to manage application objects. A single index file named Axapd.aoi automatically makes sure that the top-level version of an application object is always used. The USR layer is the top layer and the SYS layer is the bottom layer. The following illustration shows the 10 Microsoft Dynamics AX layers.

For example, when a user opens a form, a check is made to determine whether there is a USR layer version of the form. Next, a check is made to determine whether there is a CUS layer version, and so forth, until the SYS layer version is used.

Most application objects, such as tables, fields, indexes, enum types, and extended data types have unique application object ID numbers in addition to names. Microsoft Dynamics AX uses an application object ID number series corresponding to the layers, as shown in the following picture.

When an application object is created, Microsoft Dynamics AX automatically manages the application object ID and assigns a new ID. If you modify an existing object, the application object keeps its original ID and is not assigned a new ID in the same layer. If you move an application object to a new layer, a new ID is automatically assigned.

Note- If you delete the layer file, you should also delete the index file to make the system regenerate it.