Native database

Marketing is nice as long as it matches the reality. With Microsoft Dynamics NAV 2013, Microsoft has promised a lot of improvements, but how well does NAV 2013 stand the reality test? Apparently, outstandingly well. Over the past two days, I have intensively tested NAV 2009 and NAV 2013 through a series of five different tests that measure different aspects of NAV data handling.

Absolutely. The world needs to move ahead. The technology advances. Who doesn’t want to keep up with the progress, stays behind. That’s how it has worked since the dawn of civilization. I can’t know the exact reasons why Microsoft has decided to stop support for the Classic client with NAV “7”, but I can offer my view and position on why I believe this was absolutely necessary.

Yesterday, during a coffee break at the What’s New in Microsoft Dynamics NAV 2009 Technical for Application Consultants training in Vilnius, Lithuania (a fabulous place, by the way), a discussion arose around the destiny of the Classic (or C/SIDE) client in NAV.

Early versions of SQL Server option for Microsoft Dynamics NAV (then called Navision) didn’t scale up as high as one would expect. Although SQL Server itself could scale up to thousands and tens of thousands of concurrent users, running a production environment of an ERP system is way different from running generic lab tests.

One of the choices a customer interested in Microsoft Dynamics NAV must definitely make is the choice of the database platform. With NAV, there are two possible options: so called native database server, which is not really officially called that (the official name is Microsoft Dynamics™ NAV Database Server), and Microsoft SQL Server.

Tons of documents exist about Microsoft Dynamics NAV, but most of them start with marketing lingo, and don’t wander away too much from it altogether. While it is nice to know that it is a system which will give you freedom to focus on your business, it is also nice to know what is it made of, and how it works inside.