Mark Brummel - Author of Microsoft Dynamics NAV 2009 Application Design

Mark Brummel - Author of Microsoft Dynamics NAV 2009 Application Design

Metadata Corrupt in RTC | Experiences

Today, something terrible happened at one of my NAV 2009 RTC customers.

After importing a fob with a changed report layout, sudenly people started calling me (I was working from home) that they were kicked out of Navision (yes, they call Dynamics NAV 2009 Navision, wonder where they got that from). Someone even called it a Navision Crash.

I seemed that for some transactions NAV returned an error message Meta Data not found, or Object Meta Data has changed. First for table 2000000073. So I deleted that metadatarecord and it was fixed, but then it other tables start to fail. Same solution. Then, Table "Object"... Hmmmm. You cannot manualy compile that table so I was stuck.

Sweat... (And I can stand a lot of stress, believe me)

Fortunately most main processes still worked, only a few sub processes failed.

Then, we found out that the configuration was also corrupt. When personalising a page or menu NAV would simply crash and only restart if you delete the User Personalisation records.

Sweat more...

I restarted the Service Tier. No changes.

Shutting down NAV completely was not an option since that would shut down business critical processes.

So we decided to keep it like that, knowing that some processes did not work and look at it later.

To save time I decided to create and restore a backup to try to simulate it. This is where the story becomes really strange.

When doing the same processes that failed in prodution in the restored database everything worked. And I did not change ANYTHING. NOTHING!

I tested and tested but could not find it.

We decided to do the same for the production system this evening. And it seems to work. The metadata messages dissapeared. Like snow in the sunshine.

Wait, it becomes even stranger.

I reused the Production service tier for the new production database and attached the old production database (nothing changed, same database) to another service tier we use for whatever. (read: never). And also in this service tier the problems are gone.

So my guess is, that the problem is caused by some configuration file somewhere. I hope Microsoft reads this and a developer has an AHA erlebnis.

Hopefully this was a once-in-a-lifetime experience, but next time I know what to do

Cheers,

/Mark

Posted: 2010-9-8 22:09 by Marq | with 8 comment(s)
Filed under:
Bookmark and Share

Comments

Marcel Lathouwers said:

Hi Marc,

My first guess would be to get to the latest platform hotfix.

Recently we bumped into strange behaviour, when a object was compiled from a hotfixed client, while the service tier was on the vanila build.

Regards,

Marcel

# September 8, 2010 10:45 PM

Steve Knott said:

Welcome to RTC.. .

Happened a few times to me.. fortunately small clients where I could kick everyone off...

Ditto your comment re MS sorting out.... it is needed.

Thanks for the blog

# September 8, 2010 11:16 PM

Marq said:

@Marcel,

The buildnumbers are the same, only difference is that my local database was a native database, not SQL.

Maybe there is a difference between the fin.exe and finsql.exe.

The fin.exe does not have to compile .net off course.

Is there a stable build that MS recommends to use? From my SQL Perform times I can remember that not all hotfixes are improvements. ;-)

# September 9, 2010 9:54 AM

waldo said:

I agree with Marcel .. I experienced the same issues when I use wrong build-numbers.. .  

But as you said, they were the same, so that's not the case, probably.

Anyway, it's a golden tip: ALWAYS KEEP YOU BUILDS THE SAME!!  Classic, RTC, Server, NAS .. everything!

# September 10, 2010 9:07 AM

Dean McCrae said:

Mark, without sitting down at the system and debugging it is hard to know what's going on here.

My only guess is that the versions in the Object Tracking table are out of sync with the database (there have been bugs on this in the past). But this will not cause entries to be deleted from the Object Metadata table!

The restore from another database will perhaps set versions that are less than the latest version in the database, thereby 'correcting' the problem.

I think the problem with the personalization causing a crash is a totaly separate problem actually.

# September 10, 2010 11:42 AM

Vjekoslav Babic said:

Something similar happened to me, regarding corrupt data in Object Metadata table with Report Layouts. For some reason, for two times already, an report stopped working in RTC, however compiling luckily sorted it out, and no errors with Object Metadata table. The problem is - this pops up just out of a blue, and I am sure the same report will stop working again.

Now having read your blog post, I'm starting losing hope :(

# September 10, 2010 12:08 PM

Marq said:

Hi Dean,

Thanks for reading this.

Deleting records in the metadata table were deleted by me hoping that recompiling would solve my issue.

The personalisation went corrupt at exactly the same moment. It started with customised views do be duplicated. (Actualy it showed it five times).

You know the structure way better than I will ever do. Next time I have this (hopefully never) I will call you. ;)

See you next time in Vedbaek.

/Mark

# September 10, 2010 3:50 PM

Navigate Into Success said:

We old dogs really have to learn new tricks with RTC (RoleTailored Client), as I found out couple of

# September 12, 2010 12:37 AM
Leave a Comment

(required) 

(required) 

(optional)

(required)