We all use records. And we all used to whine about records not supporting all the features we need. And they still don’t, but in Microsoft Dynamics NAV they support much more.
Some of the new features are well documented, some are somewhat documented. So here’s what I figured out so far is new about the Record data type.
Taking a quick glimpse over now largely defunct symbol menu and what it has in store for a Record variable, shows a bit more content in the Miscellaneous group than in NAV 2015:
Of these five new functions, I find the ISTEMPORARY function the most useful. Until now, the only way to see if a Record variable refers to a temporary table was to create a RecordRef over it, and then check its ISTEMPORARY function. Now we can skip an unnecessary variable declaration and an additional line of code.
If you wonder why would you want to check ISTEMPORARY on a Record, because you declare a variable, and you know what it is – then consider all those situations where a record variable is passed by reference. When a record variable is passed by reference it carries with itself its temporary state.
Similar to ISTEMPORARY, we can now read the RECORDID of a record without having to declare a RecordRef and get a record reference over a record variable. Again, some declaration and come coding is saved.
Finally, the CURRENTCOMPANY function tells you which company the record variable is currently looking at. On top of Record, this function exists for the RecordRef data type as well.
SETASCENDING and GETASCENDING can be used to fine-tune the sorting on a record variable. With SETASCENDING, you can sort in ascending or descending order on an individual field. Combining multiple SETASCENDING, you can sort on one field in ascending order and on another field in descending order. Just remember to include the fields you want to sort by in the current key. For example, this piece of code sorts the Customer table on Location Code field in ascending order and Responsibility Center in descending order:
And the last, but not the least, is the possibility to add the timestamp field to every table. This allows for many scenarios, such as synchronizing data between different applications, or checking whether a record was changed by another process.
This last feature is implemented in a strange way, to say the least. Even though SQL Server already keeps a timestamp column on each table (and it has done so from the very first release of NAV on SQL) you need to manually add a field of type BigInteger, and set its SQL TimeStamp property to Yes. Doing this does not add a new physical field to the underlying table – it merely instructs NST to convert the timestamp value from SQL to a big integer value for you to consume. The funnies of all, this timestamp field is retrieved from the database anyway – so having to add it manually is slightly confusing: even though it already exists, even though it is retrieved from the database anyway, you need to create that field for those tables where you will be using it. The only benefit of this procedure, as far as I can tell, is being able to give an arbitrary name to the timestamp field.
It would have been way simpler to simply add an implicit field named timestamp to each table, but it’s still okay the way it is. Much better than it used to be.
All in all, there are quite some improvement to the record table, and I am happy to see the C/AL stack getting increasingly stronger with each new release.
