Rethinking Dynamics NAV Object Versioning
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.