Start of this year we upgraded our NAV 2016 installation to NAV 2018 RTM. And February 26 we were live. It was a relative smooth and fast upgrade and we were quite pleased with it. We ran however into a couple of performance issues of which one them exposed itself immediately after go-live. We were pointed to it by one of our sistering team's consuming a number of NAV web services in their application. But unfortunately we couldn't get a hold on what was exactly happening, so it was lingering until a month or so later we were confronted with a seemingly different issue, but with the similar pattern.

Our sistering team reported that, while sending data to NAV through a web service the following exception occurred frequently:

For search engines sake, let me phrase the essential part of this even viewer screen:

The sql connection doesn’t have a database instance attached. This must not happen if the connection comes from the pool.

We had no idea whatsoever on where to find the cause (and solution!) and we let it be for the time being. It was not a showstopper in the operation as the major part of the web service calls were successful. Until some 6 weeks later, when a new project had started with an external partner connecting to a new web service, experiencing a same kind of issue. Roughly every 10th call connecting to NAV failed resulting in a 1000 longer waiting time and timeout:

“
Apr    25     07:33:01     Update box:   Time:  273    ms
Apr    25     07:34:02     Update box:   Time:  278    ms
Apr    25     07:35:01     Update box:   Time:  285    ms
Apr    25     07:36:01     Update box:   Time:  274    ms
Apr    25     07:37:02     Update box:   Time:  282    ms
Apr    25     07:38:01     Update box:   Time:  279    ms
Apr    25     07:39:01     Update box:   Time:  288    ms
Apr    25     07:40:02     Update box:   Time:  355    ms
Apr    25     07:41:01     Update box:   Time:  272    ms
Apr    25     07:42:02     Update box:   Time:  272    ms
Apr    25     07:43:01     Update box:   Time:  266    ms
Apr    25     07:44:22     Update box:   Time:  21.40 sec
Apr    25     07:45:02     Update box:   Time:  291    ms
Apr    25     07:46:01     Update box:   Time:  280    ms
Apr    25     07:47:02     Update box:   Time:  285    ms
Apr    25     07:48:01     Update box:   Time:  274    ms
Apr    25     07:49:01     Update box:   Time:  268    ms
Apr    25     07:50:02     Update box:   Time:  290    ms
Apr    25     07:51:01     Update box:   Time:  291    ms
Apr    25     07:52:01     Update box:   Time:  272    ms
Apr    25     07:53:02     Update box:   Time:  288    ms
Apr    25     07:54:01     Update box:   Time:  283    ms
Apr    25     07:55:01     Update box:   Time:  284    ms
Apr    25     07:56:02     Update box:   Time:  276    ms
Apr    25     07:57:01     Update box:   Time:  282    ms
Apr    25     07:58:02     Update box:   Time:  270    ms
Apr    25     07:59:23     Update box:   Time:  22.29 sec
“

Our request for help on this issue towards MS was answered very fast resulting:

Our team investigated the exception

The sql connection doesn’t have a database instance attached. This must not happen if the connection comes from the pool.

and discovered that we have fixed a bug for Dynamics 365 Business Central titled  

Connection pool - concurrency issues when disposing NavSqlConnectionScope

that has not been backported to NAV2018 (and the exception trace that you provided looks similar to the one we saw when fixing this bug)

We have created a backport bug to have this fixed in an upcoming CU for NAV2018, preferably CU 06

And indeed it was released in CU06 for NAV 2018 as hotfix 267998. Once installed it did indeed fix the issue. No hiccups when disposing NavSqlConnectionScope.

Thanx to the MS team that helped us out.