Once upon a time, a smart bloke named Saikichi Toyoda came up with a 5 Whys troubleshooting technique. It postulates that you only need to ask “why” five times to get to the root cause of any problem in a cause-and-effect sequence.
However, with .NET Interoperability in Microsoft Dynamics NAV (pick your version here), I’ve only had to ask “why” three times today, and unfortunately I could not get to the root cause, except – poor design decisions.
It all has to do with a simple .NET class: System.DBNull. The first “why” is simple: why is there no support for fields on .NET types. The second “why” is even simpler: why don’t we have a null constant in C/AL. And the last “why” downright falls into the “what the heck” category: why did somebody think it was a smart idea to replace DBNull value with null.
Continue reading Three Whys about .NET Interoperability
Handling Excel files in NAV 2013 (including R2) is not as easy as it seems at first. The Excel Buffer table – an obvious choice of the old days – supports only Open XML format (*.xlsx), and Excel Interoperability implementation seems a bit buggy (check the comments in my old post about .NET interoperability: http://vjeko.com/blog/the-beauty-and-the-beast-nav-and-net). You can still use automation, but then you must handle everything, or at least most of it, on the client end. And, to make it all just a bit worse, none of these approaches, even when they work, will impress you with their speed. All in all, if you want to handle legacy Excel files (*.xls) you will have to make some compromises.
Last week, Mark asked me for a bit of help on a project where he had to import *.xls files into NAV 2013, and he hit all of the possible walls provided by the Excel Buffer, .NET Interoperability components for Excel, and automation walls possible.
When I gave Mark my solution, he said: you should blog about this. So, here I am, blogging about a simple way to read data from Excel, any version, lightning fast.
Continue reading Excel Interoperability Woes in NAV 2013