NAV 2015

A couple of weeks ago, a new page was created on PartnerSource – the “Demo Microsoft Dynamics NAV” page. You can access it at http://aka.ms/demonav The page contains (at the time) two scripts and two How Do I videos that help you establish a demo NAV 2015 environment on Azure, in Office 365.

Good. At this point we know everything about exception types, what they are, how to obtain them, how to compare them (at least directly). All of these have suddenly become relevant now that we have GETLASTERROROBJECT function in NAV 2015. But an old friend is still around, the GETLASTERRORCODE function, what about it?

To continue my series about exception handling in NAV, this time I’ll discuss how to gain insight into exceptions in NAV. As I mentioned already, the GETLASTERROROBJECT function gives you an instance of System.Exception, actually of a class descending from it, which allows you to get more information about the context of the error that has just happened.

Do you know cues? Those clickable colorless stacks of documents in NAV 2009, that turned into clickable blue stack tiles in NAV 2013 R2, and that worked on top of FlowFields of type Integer? Well, in NAV 2015, this munch bunch has turned into clickable blue tiles with pictures and colorful…

In case you missed it, Microsoft Dynamics NAV 2015 is now available for download at PartnerSource. Follow this link to download your copy today: https://mbs.microsoft.com/partnersource/northamerica/support/support-news/msdnav2015download The download page contains the W1 version along with 20 country versions.

Once upon a time, and really not such a long time ago, there was no such thing as a codenit type. In all honesty, there is still no such thing as a codeunit type – there is subtype , though. (Why we have subtypes, without having types, beats me, but let’s let the semantics go.) Nowadays, we have four codeunit types.

Before NAV 2013 R2 the “database schema synchronization” was an unknown term. Either you could do a database schema change, or you couldn’t. There was no such thing as data loss. If you wanted to change a field type or delete a field (or delete the whole table for that matter), and there was data in that field in the table, you got an error.