Van Vugt's dynamiXs

[Just a note to myself as I always need to look up what to download and install on Visual Studio 2017 to allow me to work on RDLC layouts for my reports.] When opening the layout of a printable report from C/SIDE report designer Visual Studio 2017 will be opened. When you have a new installation of VS 2017, the layout will however be shown in xml format only. In previous versions of Visual Studio the issue was solved by installing SQL Data Tools Trying the same for VS 2017 will not help you…

For those of you that have been following me for a reasonable number of years: you might have stumbled across my testimonial . It clearly marked a threshold in my professional carrier, and in hindsight it was worth all the while taking it. And now I am on the verge of adding another 7 years. Next week Thursday, to be precise, when I will be down south in California, when conference season has just taken off. My conference season and a whole new training season too. May I invite me to join me in…

Or freely translated from an old Dutch saying ( Doe de deur dicht! Je bent toch niet in de kerk geboren?): Close that FastTab! Have you been born in church? ... meaning: keep the door closed, do not spoil the heat inside. And that's what this small post is about: have a better performance by collapsing the FastTabs on your pages. After our upgrade to NAV 2018 we experienced a number of performance issues. One I blogged about some months ago. Another concerned the loading time of the Item Card…

Start of this year we upgraded our NAV 2016 installation to NAV 2018 RTM. And February 26 we were live. It was a relative smooth and fast upgrade and we were quite pleased with it. We ran however into a couple of performance issues of which one them exposed itself immediately after go-live. We were pointed to it by one of our sistering team's consuming a number of NAV web services in their application. But unfortunately we couldn't get a hold on what was exactly happening, so it was lingering…

More or less coincidentally I stumbled over the topic of this post a couple of weeks ago in my next endeavor to raise the success rate of the MS test suite on our solution. A task being picked up every once in while, next to all the normal work. The major approach so far in getting as much as possible MS tests working has been a statistical one: look for the most occurring error and get it solved; subsequently take the next most occurring and so on. In 1 week the success rate raised from 23…