Nav Source Control Options

If you work in development team you know how important it is for the team to be up-to-date with the latest changes and newest features that are being created. Even if you are a contrator, the importance of keeping up with the rest of the team is vital. So how can you do this with Dynamic Nav? Usually, with any programming or development related task you would use source control. Git, Mercurial, and Team Foundation Server are all really useful tools. Except.

Dynamics Nav and source control do not go well together. Inherently putting a database in source controlling is always a very difficult thing to do. Since Nav is entirely built on an SQL database it has difficulties integrating with source control. What options do we have?

Lock Tables

Nav does have a built in feature to be able to lock tables that you are working on. This lets everyone in the system know that you are working on this object and that no one should touch it once you are done. This method has many, many issues. First you can only have one person working on an object at the same time. This can massively increase the time it takes a team to accomplish a task.  Since each person on the team might need to make small changes to the same object. Codeunit 90 is a good example of where multiple devs might need to make changes all at once for slightly different tasks. The other issue with this is you do not have a history of the changes that were made. Unless you comment  and keep all the old code. You have no idea what was there after the changes were saved. Big problem if an bug comes up and you dont know how to revert things back.

An other large issue with this is that everyone has to connect to the same database. This puts strain on the server and if you cannot connect to it, well I guess you aren’t doing any more work that day.

Git, Mercurial, Team Foundation Server

(I might break these out in a later post)

These technologies have been around for a while. Although they don’t work well with Nav right away. If you try to put the full database into source control, you will have unresolvable conflicts all over the place. To make one of these technologies work with Nav you have to use text exports. If you export any changes you make to a source control system you can keep track of all the changes and distribute it to the rest of your team.  There are some issues with this method still. First, data is not kept up-to-date. Since most devs will have their own databases, they could have different and/or bad data than what should be there. Another issues is that you can easily copy over and lose any not committed changes. Say you make a change in your dev database, then you import someone else’s changes to make sure they work with yours, you could import right over top of your changes and lose them.

These are currently the two most popuarl ways to keep your dev team up-to-date with the latest and greatest about the changes your team is making to the system. There are many ways to improve these processes though.

Leave a Comment