Dynamics AX
  RSS Feed  LinkedIn  Twitter
Want to turn you're data into a true asset? Ready to break free from the report factory?
Ready to gain true insights that are action focused for truly data informed decisions?
Want to do all of this across mutliple companies, instances of Dynamics and your other investments?
Hillstar Business Intelligence is the answer then! (www.HillstarBI.com)

Hillstar Business Intelligence for Microsoft Dynamics AX and NAV on Mobile, Desktop, Tablet

Let us prove to you how we can take the complexity out of the schema and truly enable users to answer the needed questions to run your business! Visit Hillstar Business Solutions at: www.HillstarBI.com

Tuesday, March 24, 2009

The Perfect Storm - a Case for the Good Ship SourceSafe

It's Friday, everything was going along fine, and the AOS crashes. Ok, go check the event logs, note an error with an AOT object, and restart. Bang, seconds later it crashes again.

Start the AOS service, and go open the AOT to try and get to that object, which happens to be a view, AOS crashes.

There is a corrupt object in the AOT, and you can't get access to it, via the AOT to remove it.

This is what happened to me last Friday. I call it the "Perfect Storm", and the reason why will be evident as you read on from here.

So there I was, AOS crashing, and you can't get to the object that is causing the issue. You also can't import over it, as that causes it to crash as well. It's a corrupt object in the AOT.

So there is a posted blog entry out there, that talks about removing the corrupted AOT object from the instance with code. That blog entry can be found here: Deleting a Corrupt AOT Object via code.

So I took and was lucky enough that a job would come up in a private project. So I created a new job, and changed the code from the above post, to fit my needs. When it made it to the util.delete(); call, the AOS crashes.

Bang! Another wave crashing down.

So moving on, the plan was to try and take and just restore from last night's backup of the /Appl files. But wait, another storm from the other side was coming in. As the last good backup for the /Appl files is 10 days old.

This was because of an issue with the backup solution, shutting down the AOS at night, and stopping the batch job processes and nightly jobs. The backups were scheduled to start back later that night. Not good, waves crashing in even higher, as 10 days worth of work seemed to be possible it could be lost to the sea of no return.

So in a last ditch effort, a plan was hacthed, to take and try to export all the layer objects, but that single one causing the crash. The code was wrote up, based on the following:

"TreeNode treeNode = infolog.projectRootNode(); ProjectNode projectNode; UtilElements utilElements; ;

treeNode = treeNode.AOTfirstChild();

projectNode = treeNode.AOTfindChild('VarLayerChanges');
projectNode = projectNode.getRunNode();

while select utilElements WHERE utilElements.utilLevel == UtilEntryLevel::var {
ProjectNode.addUtilNode(utilElements.recordType, utilElements.name); }


The above was just changed to not include the object that was causing the crash. However when ran, this too crashed the AOS. Arrgh! Nothing that we do works.

Another wave came crashing down. It was bleak looking at this point, we were all hanging on by a thread. And just then, over the last crashing wave, a small light could be seen. Another ship? Another way out? yes! yes!

It was good the ship SourceSafe, Visual SourceSafe to be exact. So quickly we restored to the 10 days back .aod file, after making plenty of backups for the /appl files and database. Then moved on to start everything back up. After that we brought in every object from SourceSafe that had been touched since 11 days back... and the storm calmed, and the sun shown again.

We were save by that good old ship, SourceSafe.

So the moral of this story, making use of SourceSafe is a good idea. Even though it may be a pain at times to setup, and cause some extra steps for making sure things stayed sync on a weekly basis, it's worth it's weight in man hours, as it came in and saved the day!

Check back soon, as I fully recover from the perfect storm last week, and being sick yesterday, and hopefully I can get back to posting what I had planned. See you then!

I wanted to make sure and update this post, letting everyone know that the typical removing of the .aoi file from the /Appl folder location, and even removing of the object in the SQL DB did not have any affect or offer any help.

That is a typical thing to try and do, to get AX to to 'fix' it's meta data about all the objects it manages at the different layers they exists. I did not post that I tried that first, in this perfect storm.

"Visit the Dynamics AX Community Page today!"

Labels: , , , , , , , ,


Anonymous Anonymous said...

You only need it once for it to be worth all the hassle with setting it up and keep it running. Good for you during stormy weather :)

2:39 PM  
Anonymous Anonymous said...

Interesting. Any chance you can provide a working link to the job in your post? It seems te be dead.



7:07 AM  
Blogger Oscar Londono said...

Hi brandon,

I thought I was in the perfect storm too. Fortunatly, I found a solution.

Next time, use this as your last resource. May be it works!

AOS crashed due corrupted node in the AOT

2:24 PM  

Post a Comment

<< Home

Copyright 2005-2011, J. Brandon George - All rights Reserved