For future purposes: updating NAVISION 2.5 to X.x?

Moin: Our company started with NAVISION 2.5 at January 2000. Since then we/I did several modifications/additions to the original tables, forms and reports. Assumed we will update to a new version, will there be a method to get this procedure being done automatically or will we have to re-code all this? Regards Uwe Edited by - Kolja on 10/18/00 12:42:34 AM

There is something called the “Merge Tool” which (if the changes are not too dramatic) automatically combine your mods with the new base version. Usually, it is safer to make a change log of your modified version (vis a vis its base version) and then manually apply the changes to the new base version. It is best to do most of this work with an external text editor instead of the C/SIDE editor. Luckily, not every object gets changed for each new version. A lot of your modified objects can be used as is, without any re-editing. ------- Tim Horrigan

I have done lots of upgrades in the last four years. Forget about the merge tool, It won’t do any good but rather mess up tables. In realitiy you have to face the fact that you have to rebuild all your changes in a “naked” (Standard) x.xx database. Therefore the key issue is *** D O C U M E N T A T I O N ***. Document EVERY single change you perform in any table! Do not only comment your changes verbally in the Document section but also within the code itselves. Navision gives strict guidelines how code-changes should be documented and I strongly advise you to follow these guidelines. Example: If you have a project XY based on Fin 2.50, you might document changes as version XY2.50.00, XY2.50.01, XXY2.50.02 etc. In the Document section of the object you define Version, date and your signature together with the comment. Such as: XY2.50.01 16.10.00/UW - Field 50000, Storno : Boolean added * (Storno = Reversal) * functionality added to get only non-reversal GL Entries Within the code you mark the beginning and ending of your change and also make sure to include the original Navision code. //XY2.50.01 // Nur Nicht-Storno Buchungen filtern // Select only non-reversal entries in Fibuposten (= G/L entries) {orig - Fibuposten.setcurrentkey(“Kontonr.”,“Buchungsdatum”)} Fibuposten.setcurrentkey(“Kontonr.”,“Buchungsdatum”,Storno); //XY2.50.01 Fibuposten.setrange (“Kontonr.”,Nummer); Fibuposten.setrange (“Buchungsdatum”,Datumfilter); Fibuposten.setrange (Storno,False); //XY2.50.01 //XY2.50.01 - END This is the only method to make sure that you will ever find your changes again and that you will be able to reproduce what has been changed. Bear in mind, that it might not be YOU who will have the task to upgrade the db to a higher version. Needless to say that changes which do not alter the code (new fields, new keys) should also be commented. Worst I have ever encountered was the problem to lift a Fin 1.1 DB to Fin 1.3 where nothing was commented. It took me 2 weeks. After having figured out what had been changed in this DB I commented every single change with the method above. One year later, when I had to upgrade this nicely documented 1.3 db to 2.01 it only took me two days! Marcus Marcus Fabian phone: +41 79 4397872

I would like to state that the merge tools is helpful as long as you document your changes properly. In addition to what Marcus wrote, I would like to add that original code should indeed be included but the “{” and “}” sign to exclude the code from being executed should be on a new white line before and after the original code so that the merge tool can properly examine changes: //example { original code } new code //end example

There is a brilliant little compare tool that I use which displays the 2 versions of a file side by side and highlights differences, even allowing you to automatically merge one into the other. Much better than the Navision merge tool. It’s available over the net from (I think) for $100. Well worth it and no, I don’t have shares in the company! I’m sure there are other tools like this around if you go looking.