Tuesday, August 7, 2007

Delete an application object from X++

Sometimes you can just not access an element in the AOT without AX crashing in the attempt.

The first thing you can try when that happens is simply to stop the AOS, delete the Application Object Index file (axapd.aoi) and re-start the AOS to rebuild the index file.

If that doesn't work, you could try to delete the element from X++. Here's an example for a job to do that:

static void Job1(Args _args)
TreeNode treeNode;
TreeNode treeNodeTable; ;
treeNode = TreeNode::findNode(#TablesPath);
treeNodeTable = treeNode.AOTfindChild('Table1');

A third option would be to export everything from the layer where you have the problem. Remember to export with ID's. Stop the AOS, delete the the Application Object Data file (ax.aod), re-start the AOS and re-import the exported layer. This third option is of course only applicable for layers you have development access to.


Anonymous said...


would be so kind as to elaborate on the pros and cons of "export with ID's" option.

in this context and when moving code from one instance to another?

I have never found a complete explaination of it usage and pro's/con's?


Palle Agermark said...

Well, let me try to briefly explain why the id's are important.

Many element of AX are identified through their ID´s and not their name. AX is for example using ids for controlling how the table metadata are syncronized to the database. If you for example export and import elements between a two applications without id's you will no longer be able to move the file holding the entire layer (for example axvar.aod) without risk loosing data in the syncronization process.

Id's also allows you to be able to deploy renamed elements. Without the id's AX would get that you renamed the object and you'll end up having both the old and the new element in the destination application.

There's some good reading about ID's in the book "Inside Microsoft Dynamics AX 4.0". The book can be downloaded for free from Microsoft: