This week after NAVTechDays I started upgrading one of my more complex customers to NAV2017. We have several reasons to do this.
Eventually we want to use the Outlook Add-In for a project next year to improve the sales data and reduce invoice errors.
My first reason was to use Notifications. I had already built something like Notifications in the classic client which was very easy with the Wysiwyg controls and we lost this when upgrading to NAV2016.
Then we got another reason. Job Queues. In NAV2016 they sometimes keep hanging over maintenance jobs in the weekend or during other scheduled or unscheduled system tasks.
Job Queues got improved in NAV2017 and are now part of platform and multithreaded. They came a long way since they ran as a Form with a Timer.
Funny detail is that the system table is not called Job Scheduler just like the first one.
Since we have a huge amount of users in multiple locations and countries and quite a large database we decided to break the upgrade down in smaller pieces and start with a platform upgrade.
This is quite easy and does not take more than a few minutes but during testing I ran into this error message:
“Call to the function ‘LOCKTABLE’ is not allowed inside the call to ‘TryPrint’ when it is used as a TryFunction.”
This made me smile since I actually managed to implement try functions during transactions. I have to fix this but I decided to move that to a later point in time when I do the Application upgrade.
NAV2017 has a new key called DisableWriteInsideTryFunctions which by default is set to TRUE. This is perfect but not when you run a platform upgrade since NAV2016 actually supported this.
The reason not to go for full upgrade is end-user training. The UI of NAV2017 has changed so much and I don’t have time to train all the users in the timeframe I want the platform improvements to work.
It’s not because merging is a lot of work. In NAV2016 we have implemented a lot of events where possible and hooks where there were no events.
You can upgrade Job Queue to the NAV2017 objects quite easily since they are isolated. The only change is in Codeunit 41 where is calls into a Job Queue Codeunit.
If you don’t remove this reference NAV will do an App Crash with no usefull log.
The very first second I spun up the 2017 instance and started testing everything just felt so much more responsive. This was noticable since the database runs on a very slow file system. (To be fixed in December by adding more HP)
The session high on my list for NAVTechDays was this one. I ended up having to miss it because I got stuck at our booth.
This was the 3rd video I watched from NAVTechDays and definately one of the the most interesting ones. I never realised Microsoft had made such big performance improvements to the core stack that on-prem customers would benefit from.
The reason I love NAV is because its simplicity. Something I felt was getting lost last few years by adding components like PowerShell and Azure.
Saas takes all of this away and makes NAV simple again. I will blog more about this in following blogs as I will continue to explore NAV2017, Dynamics 365 and AppSource in my new role as CTO of the Dynamics App Alliance.