Stuff about installation and development in Microsoft Dynamics NAV and integrated products.
After the Dynamics NAV 2018 CU2 release, I found it safe to upgrade my own Dynamics NAV 2016 solution up to Dynamics NAV 2018. But not only that, ALL changed objects should be transferred to extensions.
My system is a small solution and it started in NAV 4.0. On every upgrade process, I have tried to kill all the changes in the system and to start all over, in order to utilize as much of the new standard functionality as possible. The upgrade process has been through a number of stages since 4.0:
4.0 -> 5.0
5.0 -> 2009
2009 -> RoleTailored 2009 R2
2009 R2 -> 2013
2013 -> 2016
2016 -> 2018 Extension V2.0
In short, I have taken all the beatings I possible could (maybe except the RoleTailored 2009 – I didn’t have the stomach for that), in order to experience what my customers would be going through later on.
Because of my conservative approach, there are only a limited amount of changes:
So, this should be a small and affordable solution to upgrade and here are my experiences.
I found the upgrade procedure, which was very helpful, here:
Firstly, the normal procedures:
The only solution is to upload a Developers License to the database and start over.
The big problem here, is that I have customers with add-on solutions from all over Europe. And I do not have one Developers License that covers all the objects.
This means that just converting the database can take as much as one whole day [:(]
The rest of the upgrade process with importing the upgrade objects and running the upgrade process were performed more or less as described in the Walk-Through from Microsoft.
In order to move the data from my tables in the 50.000-99.999 area to an extension, the next task was to rename all the old changed tables to be prefixed with the word “Old”. This is to ensure that I could have the new tables from the extensions with exactly the same name.
A tip is, to make sure that all tables, that are to be converted, are exported as Text before the renaming, otherwise it will be necessary to rename all table references later.
Now the new tables can be built.
The process I used was to export and convert all tables using the script described in my previous blog:
After the conversion, it is necessary to clean up the files, and it is recommended to start with the master tables, so they are available when cleaning the all other tables that reference them. Otherwise the Intellisense does not work. The cleaning consists of the following tasks:
Or like here
And all other multilanguage captions must be removed to make it look like this:
In Dynamics NAV 2018 on-premise, it is possible to isolate the functions using dot-net in a codeunit developed in the C/Side Development Environment and call functions in that codeunit from the extension. That is not possible in Dynamics 365 “Tenerife”.
After this it is necessary to create an Install Codeunit to copy the data from the old tables to the new tables.
It is essential that this codeunit is built to be run multiple times. Otherwise the Install function will fail the second time it is installed.
In order to view both objects from the extension and from other objects in the 50.000-99.9999 object range, it is necessary to set up Dynamics NAV to run both C/Side and AL side-by-side. This is described here:
Otherwise it will not be possible to see both the old tables and the new tables defined in the extension.
I managed to create extensions for:
There were a number of objects that stayed in the C/Side Development Environment:
Luckily for me a new CU was released immediately after I upgraded to NAV 2018 CU2.
That meant that I could test the upgrade process.
So, now all I have to do is this:
Installing the NAV 2018 CU3 objects also fixed the small error that prevented me from posting sales orders
So now I am down to only two changed objects in my database.