Skip to content

Dynamics NAV and Object Versioning

Microsoft Dynamics NAV MVP developer's thoughts on version tags

I have been rethinking a lot lately of what I know about Dynamics NAV development. When I started this career, 11 years ago, it was my first job and I simply accepted the way of doing things. The people I worked with had been doing this longer than I had; they knew more than I did, so I followed along. As I have gotten older, and not necessarily wiser as many of you may say after reading this, I have started to challenge some of what I learned.

Version Tags

For example, what do we actually get from a version tag on a NAV object? We can tell that someone has modified the object and we can avoid errors when importing fob files into another database. These are the two things we are supposed to get by versioning our objects, but do we actually?

Well, no, we do not.

A changed version tag on an object does not mean that the source code, properties, or anything else about the object has been modified. The converse is also true. The lack of a version tag does not mean that the object is unmodified. Using the version tag alone I cannot tell anything about the history of an object.

When performing an upgrade I do not rely on the version tag to tell me which objects to merge. Moreover, once the version tag has changed all links to how that object has changed over time are lost (at least when looking at the version list). There is only one thing that tells me if an object has changed for sure, and that is a comparison to the base object.

Import Worksheet

That leads us into the second use of version tags: the import worksheet. The import worksheet works by checking the modified flag on the existing object and the version tags on the new and existing objects. Generally this works fine, but we should be honest with ourselves about what we are doing here. We are assuming that code we are importing contains all of the code in the current database, plus our customization. We do not know that for sure. And, I am not sure that I am ok with that anymore.

We live in a world where it is extremely easy for any person with the appropriate permissions to modify NAV. A development license is not needed to add fields, change properties, create objects, etc. And, let’s be honest, we have all seen databases where production was modified directly. The modified flag may help us in those cases, but not the version tag.

I am left wondering why we do this. I think the version tag is outdated and even when it is used it does not provide detailed enough information to be useful. Without detail, a version tag of “XYZ” means just as much as “XYZ10.00.001”.  Without detail, a version tag of “XYZ” is useless.

What are your thoughts? 

Please let me know if you agree or not by commenting below. You can also contact me directly.

If this topic interests you, be sure to subscribe to our Dynamics NAV Developer blog.



Agree that version tags are not to be trusted but they have there time and place.

I like being able to see my current version tag on a base object that might be having an issue.  That way I can see if there is a more recent version of the same object that might have fixed an issue.

I like being able to set a custom version tag for the stuff I am creating so it makes it easy to filter when exporting the objects to import into our Production environment.

I keep track of my version tag in the comment section of the object so I do have a bit of the history of the version tag.

I never trust version tags in real life.  Instead I have a simple xmlport that exports the object list from our Dev environment and from our Production environment and I use Beyond Compare to see any differences.  The reason this works so well is that the object list contains the blob size (as well as last modfied date) so if there is any difference between our Dev obejct and Production object it highlights the object.  This is how I keep Dev and Prod in Sync.

A few other thougths (I think I am getting a little off topic):

1) I have an excel spreadhseet where I track every object that needs to go into our production environment or that has already gone in.  The spreadsheet ties the version tag to the object with a description so I know what objects I changed, when I imported it and what the change consisted of.

2) Before importing objects into our Live environment I also create a backup of the objects that are about to be changed so I can roll them back if needed.


Read ArcherPoint's Blog Follow us on Twitter Follow us on Facebook Follow us on LinkedIn Link to our RSS feed Watch us on YouTube
Get Help Now