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)
{
#AOT
TreeNode treeNode;
TreeNode treeNodeTable; ;
treeNode = TreeNode::findNode(#TablesPath);
treeNodeTable = treeNode.AOTfindChild('Table1');
treeNodeTable.AOTdelete();
}
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
2 comments:
Hello,
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?
thanks.
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: http://download.microsoft.com/download/2/5/8/258C8894-B94A-4A87-81EA-4DBB9776F8F2/622579eBook.pdf
Post a Comment