New release of the CGI Code Review Tool for Dynamics AX

I am happy to announce the new release of the CGI Code Review Tool for Dynamics AX.

Only AX 2012 version is supported this time, but should you need an AX 2009 version, please let me know and I will prepare and upload an extra XPO.

In earlier releases of the tool, user might see that comparison tool didn't show the exact change for overlayered objects in some cases. This has been fixed now.

Enjoy.

Bug in SysQuery.getDimensionOrderBysFromQuery method?

When fields lists don't work as expected

Did you know that a field list in a single-record select-statement is not always beneficial in comparison to a select firstonly * from...  (or a static find-method)?

The thing is, when a where-clause matches a unique index (in AX 2009 – a primary index), the AOS may find the complete record in the cache and return it. And if this is the very first call, it will pull the whole record anyway, in order to be able to cache it. This may be proved by debugging.

So please use find-methods where possible, because they are easier to read and maintain. And remember: a while select with a nested find-method call may actually perform better than a join – thanks to caching. Therefore do measure performance to confirm that your select-statement is the most optimal one.

Table extension framework

There is a great article on how to use the table extension framework in AX 2012.

Keep in mind that if the parent table's primary key is not RecId-based, but the table has CreateRecIdIndex property set to Yes, then the relation on step #1 should be created based on "Single field AlternateKey based"; otherwise the new feld will potentially have wrong type, and it will not be possible to use it in the SysExtensionSerializerExtensionMap map.

And remember to add a DeleteAction to the parent table.

Looking for EDTs with broken table relations

The other day I found a couple of EDTs with broken table relations and wrote a script that found even more EDTs with the same problem.

Broken relations look like this:

static void findBrokenRelationsInEDTs(Args _args)

{
    #AOT
    #TreeNodeSysNodeType
 
    TreeNodeIterator iterator;
    TreeNode         edtTreeNode;
    TreeNode         relationsNode;
    TreeNode         relationNode;
    ;
 
    iterator = TreeNode::findNode(#ExtendedDataTypesPath).AOTiterator();
    if (iterator == null)
    {
        throw error("Cannot create tree node iterator");
    }
 
    edtTreeNode = iterator.next();
 
    while (edtTreeNode != null)
    {
        relationsNode = edtTreeNode.AOTfindChild('Relations');
 
        if (relationsNode.AOTchildNodeCount() == 0
         || edtTreeNode.AOTname() like "DEL_*")
        {
            edtTreeNode = iterator.next();
            continue;
        }
 
        relationNode = relationsNode.AOTfirstChild();
 
        while (relationNode != null)
        {
            if (relationNode.sysNodeType() == #NT_DBTYPENORMALREFERENCE
             && (relationNode.AOTgetProperty('Table') == ''
              || relationNode.AOTgetProperty('RelatedField') == ''))
            {
                error(edtTreeNode.AOTname());
                break;
            }
 
            relationNode = relationNode.AOTnextSibling();
        }
 
        edtTreeNode = iterator.next();
    }
}

Output:

Which query range should I select?!

Customer asked me to figure out which "Customer account" should be selected in a query. There were three of them on the Customer invoice journal table:

Apparently, there were a couple of fields that used the default label, and I found them in the following way.

Selected the first "Customer account" range:

... right-clicked in the field value and selected Record Info:

... in the dialog, clicked on the Script button:

... pasted the clipboard to Notepad:

The extended field ID was 65540.

Then, I selected another range:

... and repeated the process. The second field ID was 81625. Finally, I selected the third Customer account range and found that it was based on the field ID 81626.

So, the three field IDs for CustInvoiceJour table were found. But what were the field names?

static void printFieldNames(Args _args)
{
    print fieldId2Name(tableNum(CustInvoiceJour), fieldExt2Id(65540));
    print fieldId2Name(tableNum(CustInvoiceJour), fieldExt2Id(81625));
    print fieldId2Name(tableNum(CustInvoiceJour), fieldExt2Id(81626));
    pause;
}

And the output was:

Somebody did not follow the Best Practices for Table Fields:

AX 2009: Extra BP check for report designs

Sometimes new report designs are created by duplicating original ones. AX adds postfixes to cloned controls automatically to keep names unique, but should there be any references to report controls in the code (say, in executeSection methods), those must be fixed manually.

If this is not done, there will be no compilation errors, but the code in the new design will point to report controls located under the original design, which does not make sense at run time.

I have customized SysBPCheckReportDesign class to check if the code must be fixed in the new design. The customization is based on the standard cross-reference functionality. There was one issue with that: some report control names were cut in the xRefTmpReferences table, so xRefName EDT had to be extended. xRefTmpReferences table is not customized, but it is included to the project, as it should be re-compiled after the project is imported and data dictionary is synchronized.

You can find the XPO here.

And this is what the imported project and the new BP errors look like:

Off-by-one error and UtcDateTime

It looks like some developers think that DateTimeUtil::newDateTime(01\01\2006, 86400) will result in 01-01-2006 11:59:59 PM.

In fact, it will be 02-01-2006 12:00:00 AM.

Be careful when defining ranges for UtcDateTime fields.