When testing the upgrade process, it’s a good idea to make a backup after every significant step, such as after importing Step 1 upgrade objects, after completing Step 1, after converting the database, and so on. This way you can always resume from the last meaningful point and save a lot of time, as compared to always running the whole process from the beginning.
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 indicators that are configurable per user, that work on top of any kind of numeric fields (normal or abnormal), or better yet, on top of any kind of numeric expression (you can bind them to RANDOM(1000) for all NAV cares).
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
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. NAV 2009 SP1 brought along the Test and Test Runner types, which – in my experience, at least – haven’t seen much runtime (which is a pity, if you ask me). And now NAV 2015 brings along another type: the Upgrade codeunit type. The mere sound of it makes my heart thrill. The Upgrade codeunit. Mmm.
To open the page object for a page part control in a page you are designing, simply select that page part control and press Ctrl+F12 (or View > Go To Definition).
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. Data present – no go.
However, with multi-tenancy, and the possibility to mount tenant databases originating from different applications, suddenly there was an issue – how should NAV handle possible differences in database schema for different tenants? Should we force the change at the cost of data loss? And thus the term “database schema synchronization” entered the vocabulary of regular NAV Joes.
Thanks to everybody who attended my session at Directions US in San Diego today. It was a pleasure to deliver it, and I hope you enjoyed it as much as I did. It surely would have been much better if I were not running some kind of a flu, but I won’t complain.
As promised, I am making all the content from the presentation available for download from my blog, so please feel free to download any of it, and (ab)use it in your real-life projects.
Did you ever need to identify the current object type and ID, programmatically, from within the object? For example, detecting the current table ID in a table trigger like this guy? Or current codeunit ID from inside the codeunit?
Why would you need something like this? If you are inside a trigger in, say, table 18, you do know that you are in the table 18, and you can refer to it as 18 or DATABASE::Customer, right? Yes, but this is hardcoding. If you move this code to a different table you’d have to change the hardcoded constant to whatever that other table is.
Microsoft was well aware of the need to know the currently running object ID in some cases, because there is the OBJECTID function to the CurrPage and CurrReport built-in objects. However, for tables, codeunits, XMLports, and queries, there is nothing of the sort.
Now, using .NET Interop, you can easily (well, easy is relative) get this info.
When importing files using XMLports, and especially when handling text files, file encoding is important. If the XMLport expects ASCII, and you feed it UTF-8, you may get scrambled data. If you have mismatching unicode input files, it may just fail altogether. Therefore, making sure that encoding is correct before you actually start gobbling input files might be important.
At least it was for me. I am currently automating data migration for a major go-live, and I am feeding some 30 input files to NAV, and I want to make sure they are all encoded correctly before I enter a process which would take another geological era to complete.
Detecting encoding is not something that pure C/AL can help you with, so I naturally went the .NET way. My position is that there is nothing a computer can do that .NET cannot. My another position is that there is no problem that I have that nobody before me ever had. Combining these two, we reach a yet another position of mine, that there is nothing that computer can do, of which there is no C# example, and typically I look for those on http://stackoverflow.com/
So, here’s the solution.