Debugging Tip for Dynamics Ax

Few tips for debugging….

> While debugging I observe that several people abruptly stop the execution. This can result in corrupting the data like blocking a journal, ttsbegin/ttscommit imbalances. It is always better if we instead direct/drag[Use run to cursor ctrl + F10] the execution cursor to a throw error statement. This will throw an error and rightly revert all changes made so far through the execution preventing any data corruption.

> When we debug errors it is easy to reproduce since we can use the same data. But if the case is something like imbalance in amount posted during invoice then every time we create a new order again as the data can’t be used anymore. In these cases it is easy if you write an “throw error” statement at the end of the execution. This will prevent the order from being invoiced and you will be able to reuse the same order until you find the error.

…… Better debugging 😉

Debug::assert statements found in Sys layer in Dynamics Ax 2009

This morning I was surprised to see Debug::assert statements in Sys layer table object as I was traversing the InventTrans tree node.

[Sorry for wrongly pressing the panic button… 😉 This seems to be pretty common with new versions of Ax. Please see comments from Kashperuk]

If you look at \Data Dictionary\Tables\InventTrans\Methods\unpostedInvoiceIdForReceivedPurchType method then you will find more then 5 assert statements in it. I quickly checked where this method is being used from. It was called from a display method inside the same table. Luckily one of our developer have commented it during rollup upgrade. This statement can attempt to open the debugger if the assertion is false. So I guess it would be good if you would do something to prevent it.

Hope anybody from Microsoft following this blog would take it further to fix it…..

Adding a breakpoint through code in Dynamics Ax

Every time I see a warning or error, the default place where i place my debugger was at “\Class\Info\add”. I was really not happy of going each time to the same class to place a breakpoint. This week i got rid of it finally 🙂

What I did was develop a small piece of code that will automatically add a breakpoint and called this piece of code from the internal development toolbar that we have. The internal development toolbar is something like Tabax.  You can also do the same and integrate with your own toolbar/ Tabax / Ax Assist.

static void addBreakPoint(Args _args)
{
    container bpCon;
    int       vers, i;
    ;
    //Get the breakpoint
    bpcon = infolog.breakpoint();

   //Version just for reference not really needed
    vers = conpeek(bpCon, i); i++;

    //set the breakpoint
    bpCon += [@"\Classes\Info\add"];    //AOT Path
    bpCon += [1]; //Row number
    bpCon += [true]; //Enabled

    infolog.breakpoint(bpCon);
}

Refer to the article below if you want to know or create toolbar for Ax.

https://kamalblogs.wordpress.com/2007/03/28/a-simple-toolbar-for-dynamics-ax-4-0/

Lately i saw a discussion in one of the russian forums relating to where the code was inspired from. It’s been inspired from “\Forms\SysBreakpoints”.