NAV2017 | Why is it so damn fast!

This week after NAVTechDays I started upgrading one of my more complex customers to NAV2017. We have several reasons to do this.

#1 – Outlook Add-In

Eventually we want to use the Outlook Add-In for a project next year to improve the sales data and reduce invoice errors.

#2 – Notifications

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.

#3 – Job Queue

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.

Platform Upgrade

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.

Why no Full Upgrade

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.

Isolate Job Queue

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.

So what about performance

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)

Building the Dynamics 365 for Financials service

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.

Saas = Simplicity

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.


1 Comment

  1. Tobias says:

    Is it supported by MS to update the platform without updating the objects?

    Liked by 1 person

Leave a Comment

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.