The task
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 R1
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.
The Upgrade
I found the upgrade procedure, which was very helpful, here:
https://docs.microsoft.com/en-us/dynamics-nav/upgrading-the-data
Firstly, the normal procedures:
- Backup of the database and restore a copy of the original, so that I would have that as a reference when I started changing the “live” database.
- I then installed the new Dynamics NAV 2018 CU2 in a side by side installation to have both versions available.
- Converting the database is usually the easiest task but this provided a bit more hassle than expected.
- Firstly, it is necessary to make sure that the data is opened as single user.
- Normally I just connect to the database with the development environment to convert it. But, here it is a bit more complicated. After a half hour of conversion, I got an error that the conversion could not be done with records in table 2000000100 Debugger Breakpoint. So, after deleting all records in the Debugger Breakpoint table (in SQL Server Management Studio – I didn’t have the patience to start everything up again and make a codeunit) I restarted the conversion.
-
Next error was, that I didn’t have permission to modify the G/L Entry table (Yikes!).
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 the following procedure is needed to convert the database:
- Copy the data to temporary SQL tables
- Delete all objects in that number series
- Convert the database
- Import the objects in the converted database (which is possible)
- and lastly, copy the data back from the temporary tables.
- Next problem were add-on objects that were no longer included in the license but were left in the solution by the ISV. They had to be deleted.
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:
-
All object references must be changed from Table59000 or “59000” to the table name or page 59000 to page names
Or like here
-
All conditions that contains field names with spaces, e.g. Document Type ,must manually be changed to “Document Type”.
-
All conditions that contains Boolean variables must be changed from Yes/No to True/False
-
Then all Text constants must be changed from the Textconst type to label
-
And all CaptionML properties must be changed to Caption
And all other multilanguage captions must be removed to make it look like this:
-
Then all Dot-Net variables must be identified.
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:
https://docs.microsoft.com/en-us/dynamics-nav/developer/devenv-running-cside-and-al-side-by-side
Otherwise it will not be possible to see both the old tables and the new tables defined in the extension.
The Result
I managed to create extensions for:
- 9 Codeunits including the Install Codeunit
- 7 Page Extensions
- 16 Pages
- 1 Query
- 4 Reports
- 5 Table Extensions
- 10 Tables
There were a number of objects that stayed in the C/Side Development Environment:
- 1 Query because the query from extensions cannot be used in Generic Charts
- 1 Codeunit that contains the functions using DotNet
- 1 Change to a standard table (Table 36) because of an error in the standard NAV code
The Next Upgrade
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:
- Download the new NAV 2018 CU3
- Close all running service tiers (2 separate servers)
- Uninstall NAV 2018 CU2 on both servers
- Install NAV 2018 CU3 on both machines
- Import the NAV 2018 CU3 objects in my database
- Compile all objects
- Build Server Application Objects
- Start all service tiers again
Done!
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.
Nice
