My colleague Lars described in BLOG post “About Object Metadata, and why I can’t see object changed in RTC” and explained how to troubleshoot metadata update problems.
With current post I’m trying to overview whole process and make it more clearly for all.
So we have few moments I want to clarify in beginning (something like glossary).
In Microsoft Dynamics NAV 2009 (NAV) we have few parts:
- · SQL server – storing data (including objects);
- · NAV Service Tier (NST) – storing metadata and timestamp in cache;
- · Classic Client (CC) – modifying, compiling saving to SQL objects.
- · Role Tailored Client (RTC) uses metadata. It requests NST to load metadata depend on what RTC user needs to use.
In SQL server we have 3 important tables:
- · Table 2000000071 Objects Metadata – it stores object metadata and when NST needs to receive objects, it receives from this table.
- · Table 2000000079 Object Tracking – it stores last object update date – really it is timestamp of moment when object was updated. Because timestamp is increasing with any action in SQL database, then latest object update always has bigger timestamp. If timestamp for some object is bigger that cached object timestamp, then cache must be updated, because it has older object version.
- · Table2000000001 Object – it stores C/side object code and with this table we are working with CC when modify, compile objects.
There is SQL Server Broker (or Polling) – special processes track changes in table 2000000079 Object Tracking. This is described in Lars BLOG article mentioned before.
No we are going to 1st schema:
This is common flow how objects are going in NAV.
Main points are:
- 1. NST loads to cache object metadata when starts (actually when RTC connects).
- 2. CC (C/SIDE) compiles object and updates Object; Object Tracking and Object Metadata tables.
- 3. SQL Server Broker or Polling catch changes in timestamp and request to update cached object timestamp on NST.
NST and RTC metadata update process schema:
Main points here:
- · NST loads metadata with timestamps from database by RTC requests.
- · When timestamp is changed for some object in database, change listener updates NST with new timestamp and NST removes old metadata.
- · Now situation is that NST has new timestamp as RTC runs metadata with older timestamp.
- However if RTC runs older metadata, then system can detect: is there running dependent metadata which requires only new metadata here. If dependent metadata requires updated object then error about “updated metadata” is showed and RTC requests to update metadata. But if there is no dependent metadata then old object is running as long as needed (until user finishes process).
- · When the same object metadata needs to be run, RTC requires updating metadata on NST.