Dynamics NAV Code Upgrade Challenges

Nowadays, ERP technology platforms are getting constantly enhanced, providing businesses with new features and improvements in optimization. The Dynamics NAV system is no exception – with the release of its latest version, NAV 2013, many companies chose to upgrade to the latest version of the software in order to get the benefits it provides.

Upgrading the Dynamics NAV database is a complex process, the essential part of which being the code upgrade, which involves transferring all customizations made in the old system to the new version of the application. Let’s look at the basic process of a code upgrade and the challenges it creates for the developer.

Process & Challenges

Overall, the upgrade process is fairly straightforward for someone who has a decent understanding of the NAV system; essentially, all custom changes made to the NAV objects are moved to the latest objects’ version. However, challenges always present themselves.

Challenge #1: How Do We Define these “Custom Changes”?

First of all, a developer should prepare 3 databases for comparison analysis, including:

  • A clean, not customized NAV database of the same version as the customer’s database. We will call this the “Source Database”.
  • A customer’s actual database with all customizations. We will call this the “Customer’s Database”.
  • A clean, not customized NAV database of the version to which the upgrade will be done. We will call this the “Target Database”.

Having the three databases at hand, we can now compare the objects’ changes and segregate the custom code, which will be merged into the Target Database. The comparison is done object by object, using any suitable text comparison software.

For example, the images below show how it will look in the Araxis Merge program:

 

082313_2231_DynamicsNAV1.png

 

 

 

 

 

 

 

 

What the developer must do is search the cases of code asymmetry and merge the changes into the new NAV object version. There are certain rules for merging the asymmetry code cases, the basic patterns of which are presented in the following table:

Piece of code exists Action on code
Source DB

Customer’s DB

Target DB

+

+

Leave as is

+

+

Remove

+

+

Leave as is

+

Leave as is

+

Add

Challenge #2: Defining the Code

The next challenge for a developer in this process is to define whether this is actually a custom code or a hotfix applied to the old NAV version, which might not need to be transferred to the new version. This is where objects Version List and in-line code comments come in handy, such as in the two examples below:

  • The clean Source object version would have a simple version tag (e.g. Version List=NAVUS3.70). However, if the custom object’s version tag is, for example, Version List=NAVUS3.70.01.45, and we see the “suspicious” piece of code not present in any of the other two object versions, we can determine that this is the code for hotfix *01.45* for the current NAV version, and there is no need to merge it into our solution.



  • In-line code comments will be helpful if they are self-descriptive, explicitly specifying the purpose of the added code.


In the versions before NAV 2009, the following object types were subject to code merge:

  • Tables
  • Codeunits
  • Dataports
  • XMLPorts
  • Forms
  • Reports

With the introduction of Dynamics NAV 2009 Role Tailored client, some object types were changed in structure/replaced:

  • Form objects became Page objects
  • Reports were enabled for Visual Studio RDLC designer

This means that code merge is not applicable to these object types any more. The upgrade process for these object types is called Transformation and is a separate topic for discussion.

Challenge #3: Code Indentation

Another challenge during the code upgrade process is code indentation. It is really important to follow the NAV patterns so that when you import the merged object into the NAV development environment, it will accept it. This is an example of a nasty error we might get in the case of incorrect code indent:

This is where “END” keyword is not properly indented during the code merge, as in the example here:

Usually, as part of a code upgrade and upon agreeing to it with the client, experienced developers do a “code cleanse” procedure which might involve the following:

  • Omitting the custom code that is commented out. These parts of the code can be skipped, as ‘not active’, in order not to “litter” the database.
  • Omitting the unused variables declared in the procedures.
  • Removing obsolete documentation trigger comments.

The last, but not least, upgrade challenge is code optimization for better performance. This is an optional item and may be purchased by the customer. This is especially beneficial in the following cases:

  • If moving from NAV Native to SQL platform.
  • When there is a big gap between the upgraded versions (e.g. upgrading from Navision 3.7 to NAV 2009).
  • If the customer’s database is very large in size and has particular issues with locking, deadlocks or performance.

The code optimization process can be done in the same object comparison application as code merge. The process involves changing the “old” functions in the custom code to the new ones. Under such “old” functions the following is usually implied:

  • FIND(‘-‘)
  • FIND(‘+’)
  • COUNT
  • LOCKTABLE, etc.

These functions should be replaced with the new ones, which optimize the NAV data processing by the SQL server:

  • FINDFIST
  • FINDLAST
  • ISEMPTY
  • COUNTAPPROX, etc.

This optimization process can be done simultaneously with merging the custom code into the target database.

At the end of code upgrade process, it is very important to check that all objects, not only those merged, have no compilation errors. Fixing bugs that evolve during the code upgrade process requires a thorough understanding of the functionality changes between the NAV versions as well as re-design patterns applicable to the particular NAV area. For this reason, upgrading the Dynamics NAV system should be entrusted to an experienced team in order to successfully run the process and acquire all the benefits of the new system.

Have you experienced other challenges during an upgrade? We’d love to hear about them in the comments!

August 23, 2013