Some partners use the Merge tool in the NAV Developer Toolkit to attempt to merge the FULL set of objects from the old and new versions. This is not necessary and often will cause more problems than it is worth.
For the purpose of discussion, let's say that you are upgrading a database from version 3.70 to 5.0 SP1.
One common error that occurs is something like this...
Your program license does not permit you to delete the IC Partner Code field in the
The IC Partner Code field is a field that did not exist in 3.70 but has been added to the 5.0 SP1 database. Most often what we find is that partners are mistakenly trying to import the merged objects into the Customer's database when they receive errors like this. The new fields for 5.0 SP1 do not exist in the customer's database. You will not be able to import the merged text file that you created from the Developer's Toolkit into your customer's database. You must first import the text file into a base Cronus 5.0 SP1 database. Once the import has completed successfully, you will then export all the objects from this database as an fob file, and then you will be able to import the fob into your customer's database.
These program license errors also occur if the object merge is not handled correctly. The main thing to keep in mind is that there will be fields that existed in 3.70 that do not exist in 5.0 SP1 and new fields in 5.0 SP1 that did not exist in 3.70. A partner license will not permit you to delete or create fields in the NAV reserved range. However, this SHOULD NOT be a problem if the object merge is done correctly. Keep in mind that if there have been NO modifications to an object, then there is no need to import a merged version of that object into 5.0 SP1. Any data from 3.70 that needs to be converted will be handled during the data conversion part of the upgrade process. When you run step 1 of the upgrade toolkit, the data that needs to be converted will be moved over to temporary tables and then converted during step 2.
Concentrate on your modified objects. If you are going to use the NDT to perform the merge, try working with only the modified set of objects rather than trying to merge every object in the database. As a matter of fact, it will often be faster to manually re-enter your modifications in the base 5.0 SP1 database than to try to track down all of the errors that can occur with the merge. One option is to use a text compare tool to compare the base 3.70 unmodified table to your modified one, then manually copy and paste your modifications into 5.0SP1. The NDT function Compare Two Versions works well for this purpose. TIP: Make sure before you do a text compare that the language layers in the "Old Base Version" match the "Current Custom Version". This will prevent having nearly every object show differences in the Compare Tool due to captions...
Open a clean Cronus database for your Old Base Version.
Go to Tools/Object Designer.
Go to Tools/Language Module/Export
Select a file name on your computer for the export in case you should need it at some time in the future.
Select one of the languages that you do not want and then be sure to click the Delete Language text box. Select OK.
Repeat for each of the languages that you do not need.
Another thing to keep in mind when using the Merge Tool in the Developer Toolkit is that you usually cannot just Accept All Changes with a set of customized objects, because there are almost always conflicts in code that must be resolved manually. Many developers prefer to use the Compare tool in the toolkit and then copy and paste the changes manually into the new version. Compare and Merge is a tool for developers to use as they see fit, but it is not flawless, so you should always check the suggested changes and resolve any conflicts manually.
Laura K. Lake (lalake)
Microsoft Dynamics NA
Microsoft Customer Service and Support (CSS) North America