All around NAV dev and test
This week my annoyance got that high that I decided to spent some time on getting the issue fixed. I guess we all run into this once in a while: things do not exactly go the way you would like it, but, OK, you manage having some kind of work around. And, best reason of all: you need to get the thing done and don't have time for it to find the proper fix. Or most probably: you don't give yourself time to do that.
"So what was bothering you, brother Luc?", you might be asking yourself. "What mankind thrilling thing did bug you, lat?"
I really love the tiles in Windows 10. Yes, I already loved in the Windows 8, and still wonder why people were detesting it. Nevertheless, what was annoying me lately, was the fact that I could not find a tile for the Dynamics NAV 2017 Administration Shell. I did have one for the Development Shell. I even had a tile for the 2016 Admin Shell. But this one seemed lost somewhere.
As said I had a workaround, but still didn't have the tile. Finally last week I decided to spent some time Goog...., sorry Binging. No, let's be honest. Yes, I am a former MSFTy, and yes, I have been using Bing a lot, but somehow, unconsciously, I did move to Google. My guilty pleasure?
Right ... I was googling and ended up on this page: NAV 2016 Administration Shell shortcut is missing. Seeing the blog title I immediately knew who the author was. Some kind of happiness touched me, seeing your name in the Dynamics blog-o-sphere, Ibrahiem. Great that you joined the community, with a lot of valuable and practical information. And of course, thanx helping me getting rit of my annoyance.
And at the same time I owe you some kind of apology as your blog goes back already 2 years. Totally unnoticed by me. Sorry for that.
Keep us informed!
Haven't been blogging a lot lately, and then it's good to realize I am not the only NAV blogger and thus information sharing keeps going anyway. So thumps up to all my peers!
And even more it's good to know that new bloggers show up regularly. I haven't been welcoming any of them for a long time, so let's use this morning to pick up that series again. Do I hear the drums roaring?
Last week ... finally ... this guy opened his cabinet of NAV experience and knowledge. And hopefully he will keep it ajar for a long time. Offline he proclaimed this is going to be on a monthly basis. Sounds promising, not in the least as I can tell you I have a hard time gertting that done.
So go for it Jan Boes. Welcome to the Dynamics blog-o-sphere!
... or should I regard it as an early Xmas 2017 present?
Any how, I am grateful! And seeing the number of votes on my connect entry, I am certainly not the only one. So thanx on behalf of all of the voters (if I may).
You might wonder what's this all about. However, you might also recall the post I did just before Xmas last year: Hey Mr. Microsoft, My Documentation Trigger is not an Xmas Tree.
Well, apparently this has been fixed in the newest cummulative update for NAV 2016: Cumulative Update 12 for Microsoft Dynamics NAV 2016 (Build 47042). Good reason for me down load and test.
Big thanx to Natalie Karolak for notifying me on this.
Chew, it has been quite some time we met here. Feels like learning to blog again. If you have been waiting for me all that time I make a deep bow and apologize for that. It has been a very busy 8 month period starting last December bringing our NAV 2009 R2 classic environment eventually to NAV 2016 last July. And after that ... a well deserved vacation in our little house down south in France. I guess it never felt more like that: time to take a leave and enjoy live in a total different way. And we sure did.
And now back on the job again. But with one major change: we're on 2016 now. Finally. FINALLY! Over three years ago I joined Van Dijk Educatie to get their Dynamics NAV installation to the latest version, NAV 2013 R2 at that time, but due to higher operational priorities, and to my dismay, it was postponed a couple of times. But we made it. Just before our high season started, end of July, and to the satisfaction of all our colleagues. Go Live on Monday July 4th went smoothly. We had been on it for all those 8 months, getting from NAV 2009 R2 classic to NAV 2009 R2 RTC in February and then straight to NAV 2016 in July. I must say it was quite an effort from dev and test with great involvement from all. And yes, we have a nice number of lessons learned to share with you. Hope I will find time enough to get that done, here, so stay tuned.
Well, let's take the bull by the horns, as we say over here; let's start immediately. With an issue that had been bugging our operation ever since I went out to enjoy may vacation. Pure coincidence of course.
I was informed that our colleagues were frequently experiencing deadlocks on the Warehouse Request table (5765), which sounded unfamiliar to me. Looking in the history of our 2009 installation TAB5765 was hardly ever an issue, but I noticed we had some customization on this object from way back in 2012, fixing ... deadlock issues!
Apparently TAB5765 standard primary key (PK) was sub optimal:
Type,Location Code,Source Type,Source Subtype,Source No.
The selectivity of the first PK field Type, with only 2 values, was clearly to low, where as the selectivity of the last PK field, Source No., was very high. For this reason, by means of the SQLIndex property of the PK, the SQL index was changed to:
Source No.,Location Code,Source Type,Source Subtype,Type
It indeed did solve the performance issue at that time.
The PK wasn't changed by MS and we had kept the SQLIndex property customization on the PK. But clearly, monitoring the deadlocks it showed that it was using the PK.
However, looking at the SQL implementation of the PK, I could not believe my eyes:
Do you see what I mean? It's the standard PK structure:
Not the one defined by the SQLIndex property:
This is somewhat scary. Is SQLIndex not working anymore?
Technically it could have been a candidate for the Clean Team as there is no need for this property anymore since we're on SQL only since NAV 2013. But ... migrating old code that uses SQLIndex to 2013 or beyond should however implement the key as defined by SQLIndex.
Some more detailed investigation learned me the following:
I have tested this for NAV 2013 R2 and NAV 2016, but probably also applies to NAV 2013 and 2016.
Why C/SIDE has changed this way I have no clue, but it scares me somewhat.
Mr. MS could you tell us why? If not please revert to the old behavior.
Indeed as David points out the non-optimal PK should have been fixed by MS and even more, the app code also, as there are a number of GET calls that have to be restructured to reflect the updated PK structure. Here is the list of objects that are affected:
Not long after this post I reported the issue to Microsoft and they acknowledged the bug on the SQLIndex property and informed me that it will be fixed in the next Cumulative Update.
Regarding the non-optimal PK: this is still under investigation and apparently has lower priority as this has potential more impact on all installations out there.
I hadn’t checked it myself yet, but just now I saw SQLIndex issue on the PK is fixed in NAV 2017. It wasn’t yet in NAV 2016 CU11 (which we are currently running on). It should have been fixed in CU12, but I haven’t checked that and at the moment the KB page is unavailable.
Today I was informed by my fellow NAV developer from Finland, Urpo Kotipalo, that this is unfortunately not fixed in NAV 2016 yet (tested in CU15). My MS contact informed me:
Today I checked in with the team that backports bugfixes and asked that the bugfix should be applied to NAV2016. I don't know in which CU it will appear, but it will be ported. Sorry for me not following up on your original request, everything is in process right now.
Apparently we keep on running into this issue once in a while. While developing you run your objects from the Objects Designer and with each single execution a new Windows Client session is being fired. Using your valuable time and frustrating your debug session as the previous one is not valid anymore and you have to start a new one. If I recall this right it first happened when NAV 2013RTM and R2 were installed side-by-side and we got a fix for that from MS.
In the meanwhile I didn't get bugged by this until a couple of weeks ago after I created a new Azure machine for NAV 2016 which contained CU 3. As I was busy preparing various courses and needed my time for that I didn't allow myself to fix the issue, somewhat annoying my students, with every other object I launched from the development environment. Triggered by this old post showing up in my dynamicsuser RSS-feed subscription (another annoying phenomenon), and having some time today, I decided to get this thing solved for my NAV 2016 CU 3 installation.
The old post was too old for my issue, but from this I got to others. Through NAV RTC is opening for each run of object I eventually bumped on this one that helped me out fast and easy. Thanx Chris et al.
To prevent myself from having to search again next time this small blog post.