By Mark Brummel, product specialist at ForNAV
When one of my customers asked me to upgrade them from NAV 2009 R2 classic to NAV 2016, I was convinced that we would do all the reports with RDLC. For two reasons:
The project started mid-2015 and at that time RDLC was the only option. I had done several other upgrades from classic to role tailored using RDLC reports with the help of external resources.
The customer already had some hybrid reports with both classic and RDLC layout to be used with Web Services. The RDLC reports were being maintained by the internal IT department, and we knew RDLC.
The reasons for upgrading to NAV 2016 were twofold: In NAV 2009 R2, we kept running into performance limitations resulting in blocks and deadlocks, and heavy loads on the terminal servers. We also wanted to use .NET for some of the interfaces that were running in C# wrappers.
During the project, which took a little less than a year, we first focused on performance, making sure that we would reach our goals after go-live – which we did. We managed to eliminate almost all blocking and deadlocks in the system and improved the productivity of the end users. The second challenge was to make sure users could work with the new role-tailored experience. With 600 customer-specific forms and 40 modified standard forms, this was not an easy task.
As with a lot of upgrades, we ended up spending very little time on the reports. Within our team, we had knowledge of RDLC, and we were not worried about making it work.
You could say ForNAV was created during our upgrade project. During the early stages of the project, Michael Nielsen asked me if I could test a prototype of a converter he had built. I was skeptical. I told Michael that most NAV partners were trained and familiar with RDLC now, and that there was no market for a tool anymore. Maybe five years ago, but not now.
However, I wanted to do my friend a favor, and I converted some reports for Michael. Of course, I used the rubbish ones from 1998 that we still had from the original implementation.
The reports converted in less than ten seconds and looked great, and I was starting to get enthusiastic.
From the moment I converted these Stone Age reports in just a few seconds, it felt strange to spend so much time on RDLC, but how do you tell that to your customer? The project goal was to upgrade to RDLC, not to start using more external components.
We decided that we would use ForNAV as an escape strategy. If the go-live date was in danger only because of the reports, we would use ForNAV.
It’s important to understand at this point in time that there was no report designer with ForNAV, only the converter.
Needless to say, we ended up using ForNAV. As with every (upgrade) project, we ran out of time and had to cut corners to go live. We selected a one-year subscription, and converted 44 reports using ForNAV.
We were probably one of the first go-live customers, and right around the time we went into production, the designer was launched. For me, at that time, I regretted not advising the customer to go with a perpetual license.
Even though I am not bad with Visual Studio and RDLC, the ForNAV designer just makes designing reports so much easier. The features I love most are being able to use all the fields from the source tables and the snapping of the controls.
Two team members from the customer took a one-day training class and are now able to make changes and create a new report very quickly.
In future blogs, I will spend more time describing the designer, which will further explain why I like this product so much.