... that one has to wait for me to return! Ciao. CU on the internet in August or maybe even later in Antwerp in September.
Hadn't read anything about this one, so I stumbled over it too during my exploratory code compare: changes made to the post code functionality.
Click on the next image to get a full view that's readable.
See the newly added TableRelation? And the "removed" OnLookup trigger? The extended ValidateCity "function call"?
Modified TableRelation / "Removed" OnLookup trigger / Extended ValidatePostCode "function call"
A newly "added"OnValidate trigger
These changes imply that the lookup in NAV 2013 is now handled by the platform itself and so a dropdown list will be shown:
... instead of a separate window that's popping up in NAV 2009 and not providing us with the special features of a dropdown list:
Having a closer look at the TableRelation for both City and Post Code field we see that they have the same pattern:
IF (Country/Region Code=CONST()) ...ELSE IF (Country/Region Code=FILTER(<>'')) ...
Hence the dropdown list will be filtered according to the value in the Country/Region Code field on the vendor record.
As you might already have sensed from the examples above - see the changes to the functions ValidateCity, ValidatePostCode and ClearFields - table 255, where these functions reside, has been extended to include both Country/Region Code and County. If my memory doesn't fail me this addition used to be a localization in Switzerland (CH) and Spain (ES), and probably some other countries, so this is apparently one of the results of MS want to consolidate local features into w1.
The result is that when entering a post code or a city value for the vendor, that is to be found in the Post Code table, the corresponding County and Country/Region Code ( in the Post Code record) will be copied to the vendor.
Now the new function ClearFields and it's use in the OnValidate trigger of the Country/Region Code field on the vendor table will result in emptying the Post Code, City and County fields when the Country/Region Code field is changed. I am not totally sure if I am happy with that, but I'll have to try it more to give a final judgement on that.
All the above as explored for the Vendor table does apply to any entity in NAV that has "address" fields defined for.
The other day my fellow MVP Vjekoslav Babic informed us that the length of G/L Account Name in NAV 2013 has been changed from from 30 characters to 50 characters to which he added:
In NAV 2013, this change is not only about G/L Account – the length of all Name and Description fields in all master tables has been consistently set to 50.
... and let me add that this also applies to all fields that, directly or indirectly, refer to/make use of these fields.
Detailed analysis of all Text and Code fields showed me that, regarding the stretching of fields, this is only one part of the story as there are many more fields that did undergo this exercise. Have a look at these statistics:
Type of Field
# of Changes
30 -> 50
20 -> 50
20 -> 35
80 -> 250
Customer Disc. Group
10 -> 20
Vendor … No.
30 -> 35
Price Inv. Increase Code
Cust./Item Disc. Gr.
One way or another these fields have been stretched. Being fields that contain a user id, an external document number, a report name, etc. The Type of Field column contains either the exact field name (e.g. Customer Disc. Group) or a kind of consolidated name (e.g. User ID as there are various fields with different names that refer to a user id). For the complete overview and details download this Excel file.
WHAT? Didn't he wait for me and ask whether he could leave?
This is hurting us truly. This morning I stumbled across this topic in the Developer and IT Pro Help for Microsoft Dynamics NAV 2013 (Beta) informing me (in my words) that GetUidOffset function in codeunit 1 has been replaced by the Start ID (UidOffset) option on the Alter Database window. This means that the UidOffset is now managed by setup instead of code. Which as such isn't a bad thing at all. In every customer database we can now easily control this offset, but being a development organization having standard products, using an external source control system and having developers do their work in local databases and sync their code on a regular base with this source control system we have to trust that every developer has setup his development environment (i.e. NAV installation) the same way. Having the GetUidOffset function in codeunit 1 that each developer fetches form the same source control system ensures (to a much higher degree) that they are all using the right offset.
But of course: it could be only us getting hurt by this change. Nevertheless I posted the issue on connect to get the GetUidOffset function back again and let it co-exist with the Start ID (UidOffset) option, where an implemented GetUidOffset function will overrule the Start ID (UidOffset) option. If you also still need it go out there and give your vote to it.
Whether or not you think SQL Server Express is worthwhile as a production database server (see some discussion on my first post on SQL Server Express) it will get installed on one of your systems when you install NAV when there resides no "regular" SQL Server installation (yet) on it. A trivial case might be the installation of NAV 2013 Beta on a virtual machine as in my own case.
Now one major drawback of a SQL Server Express installation is that it comes without SSMS (SQL Server Management Studio). So no tool to help you doing some administrative work on your SQL Server. Just now I was needing it on my NAV 2013 Beta installation to help make a backup of the demo database and though I knew that there is a separate installation package available for SSMS I took me some time to find the right place to get is from. Now to help me get it faster the next time I now writing this blog post just for myself. Well, if needed you can also profit from it.
Download SMSS for SQL Server 2008 Express from here (both X84 and X64)
Download SMSS for SQL Server 2008 R2 Express: