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.
Since NAV 2013 we are more and more getting the full potential out of SQL Server.
In NAV 2009 (and before) it was, for example, unimaginable to setup "your own" sorting for your data retrieval as SETCURRENTKEY only allowed you to use the keys defined on the table you were going to query. Or not possible for users to sort their lists by any column, like they had been used to in, for example, Excel long time.
So now we get, more and more, the power of SQL directly accessible.
Now with NAV 2016 another step is made with SETASCENDING even though it only seems to be applicable on data processed by code (didn't get it working on data displayed in a page, temporary or not).
The next code example shows what that we can sort on individual columns (in this case Currency Code and Name).
OnRun() ShowSetAscending(TRUE); ShowSetAscending(FALSE)
LOCAL ShowSetAscending(IsAscending : Boolean) MESSAGE('Ascending = %1',FORMAT(IsAscending)); WITH Customer DO BEGIN SETCURRENTKEY("Currency Code",Name,Contact); SETFILTER("Currency Code",'SEK|USD|ZAR'); SETASCENDING("Currency Code",IsAscending); SETASCENDING(Name,NOT IsAscending); IF FINDSET THEN REPEAT MESSAGE( 'Customer %1\ %2\ %3', "No.", Name, "Currency Code"); UNTIL NEXT = 0; END
The field SETASCENDING is applied to, should be part of the sorting as defined by the current active SETCURRENTKEY. If not a runtime error will be thrown:
Cannot call SetAscending on field <field name> because it is not part of the current sorting.
Coming from a C/C++ world into NAV, ages ago, it was somewhat dismaying to feel the various constraints of the system. And true, to also feel the power of it, not in the least because of these constraints, IMHO. But hell, isn't this always the case when changing? I mean, when changing, whatever. Habits. Tools. On-premise to cloud. Your partner. Or we could be still in a honeymoon state of mind and find out the constraints later.
Well, long story short. One thing I was very surprised by was the BREAK statement in NAV. Probably I am wrong, but my head kept on saying: any programming language has a BREAK statement allowing to break out of the current loop (or switch) construction and continue just after it. And yes, NAV did have (and still has) a BREAK statement, but only within the Dataport, Report and XMLport objects.
And now, finally, after all these years [emotional sob], with NAV 2016, BREAK has become what-I-always-wanted-it-to-be, allowing me "... to break out of the current loop (or switch) construction and continue just after it."
And contrary to what the help topic title (still) seems to suggest BREAK Function (Report, XMLport), it is valid in any object now. Just try for example the following in a codeunit:
i = 6 THEN
It works just fine.
Reading the help topic in detail don't let yourself be mislead:
no BREXIT, i.e. BREAK <> EXIT
Because contrary to what the remark in the topic says (notice my red coloring):
BREAK causes the current trigger to end. When used inside a loop, such as a WHILE-DO or REPEAT-UNTIL construction, BREAK interrupts the loop and causes the current trigger to end.
Nope, BREAK will just interrupt the loop and "continue just after it". To cause the current trigger to end we already have EXIT don't we?
When you program a BREAK outside a loop the compiler will throw an error:
BREAK statement can only appear inside a loop (FOREACH, FOR, WHILE, REPEAT).