Error in Version List - NAV 2009 SP1

A couple of weeks ago I started working on a code review of two of our add-ons. One build on the German (DE) and the other on the Dutch (NL) version of NAV 2009 SP1.

The first step I take in this kind of job is to perform a simple text compare using a tool like Beyond Compare or Araxis. I compare our code with standard NAV; our current code with the previous code; I might even compare standard current NAV with previous.

Doing this for these add-ons I did hit upon a number of standard objects that my tool indicated as changed, but actually weren't. Yes, they were changed, but the only changes were in the object properties Version List and/or Date. So from a code perspective nothing had changed. For sake of ease I'll call them the false positives.

Big deal?

Well, yes and no. If it was only a couple objects I could live with that, but reviewing 1000+ of objects and finding more than 100 of them marked as changed falsely, makes my work inefficient and more error prone than needed. I want to rely on my data and don't want exceptions - at least not that many. So I logged and incident on Partner Source (9599353) asking for a fix. Now weeks later I still don't have a fix. The MS support engineer has worked on it for sure. But he's relying on other MS people and apparently a fix for this issue doesn't seem to have a hight enough priority. I fully understand that having been there, but it does not solve my issue. Nothing else to do than fix it myself.

Fix

I decided to:

  1. make a full inventory of w1, NL and DE objects in NAV 2009 SP1
  2. record if they were candidates for the false positives in an Excel list
  3. create a ObjectTime export of all these objects (including Version List - see updated tool in .zip file), that I could easily use to update any NAV 2009 SP1 database easily

Attachments

Can be found here (gathered in one .zip file).

  1. The list of the false positives can be found in the Excel file (Invalid Version List Changes.xlsx)
  2. The ObjectTime data can be found in:
    • w1 - only w1 objects: Reverse ObjectTime NAV 2009 SP1 - NAV 2009 w1.txt
    • NL - only NL objects: Reverse ObjectTime NAV 2009 SP1 - NAV 2009 NL.txt
  3. Update of the ObjectTime tool so that Version List data is also handled

Notes

  • I did not include:
    • Pages, as pages are based on and created from Forms in the MS build process.
    • Other country versions than w1, NL and DE . Embarrassed But ... if you have I am more than willing to add them to the Excel attachment.
    • Objects that have a reverse change in Version List as probably some of them had been updated wrongly for NAV 2009 (6.00) or as stated on this MS Dynamics NAV blog post.
    • DE add-ons (Germany) - there were even more false positives there regarding the Date object property.
    • Numerous forms that have been updated with respect to control IDs
  • No specific DE object was found false positive.
  • A second worksheet in the Excel file lists objects that do not have an updated Version List and Date but actually should have. I did not create any ObjectTime data for these objects.
  • I did use Beyond Compare. If I had used Araxis I probably wouldn't have made such a fuss about this all. Using regular expressions in Araxis I can easily filter out irrelevant changes in object properties.

Disclaimer

I did spend quite some hours in collecting and checking and double checking the data in the attachments. Nevertheless I cannot guarantee that the data is 100% right, even if I would. Please add a comment to this blog post if you do find errors or omissions in my data. So any other user can profit from that. Thanx in advance.

Anonymous
  • Hey Luc,

    I already filed an issue at microsoft before the RTM release of NAV2009. All the tables got a new version no. If you export an object from an earlier version (client upgrade) from a 2009 database the textfiles are the same because the new properties are in the textfile to. If you do an export in the old datase base then you see a difference. But it is only the automatically genereated new properties for 2009.

    Best Regards,

    Wilbert

  • Maybe writing on a Sunday wasn't the best to do ... as on Monday morning I had to upload a modification to my files.

    Please check and double check ... ;-)

Related
Recommended