We are not historians, but we thought that it is important to know where we come from and where are we going. Some of the current restrictions or features can be better understood if we know a bit of the history of Dynamics NAV. This is why we have added this section.
Dynamics NAV was first eveloped by a Danish firm and the program was called Navision A/S. In 2002, Microsoft bought Navision A/S and included it on the Microsoft Business Solution division. The product has gone through several name changes. The names Navision Financials, Navision Attain, and Microsoft Business solutions Navision Edition have been used to refer to this product that is currently called Microsoft Dynamics NAV. Note that all the previous names included the word Navision. This is why many people keep calling it Navision instead of NAV.
In the early 90s, with the release of Navision 3.04, the AL programming language was introduced along with the designing tools for designing screens, tables, reports, imports, batches, and functions. This way of designing the application objects has persisted over the years. Major changes were made to the designer tools later on when Pages and RTC reports stepped in with the release of Dynamics NAV 2009. NAV 2009 also introduced the possibility to use the .NET framework in the AL language.
RTC reports brought in a big change because the layout of the report had to be designed in Visual Studio, outside Dynamics NAV, to bring in the advantages of SQL Server Reporting Services technology; while the Pages changed the way of developing the user interface. Until that moment, while developing the user interface, you could just see what the user was going to see. But with Pages report you could create an indented structure to determine the fields and actions, and how to group the demand; whereas the rendering of that structure was left to the RTC client. The reason was to make the design independent of the client who was going to run it. We can perceive the benefits of this change in the architecture with the release of Dynamics NAV 2013 that brought us two new clients. We will discuss it later in this chapter.
The release of Navision Financials 2.50 brought the SQL option for Navision with itself. From Navision Financials 2.50 to Dynamics NAV 2009, two database options coexisted: the native Server and the SQL Server. With the release of Dynamics NAV 2013, the only option possible is SQL. This really makes a difference, because we can get rid of the restrictions that were only there to assure compatibility between the two options. As an example, Dynamics NAV 2013 has bought the new Query object; with this new object we can now specify a set of data from multiple tables. The query gets converted to a single SQL statement, using the SQL JOIN clause. This is something that was not possible at all in the native option. Now that this option does not exist, the restriction is gone, and we can use multiple JOIN clauses within Dynamics NAV.
The release of Microsoft Business Solutions NAV 4.0 introduced the Menu Suite, which completely changed the menu structure of the product. This was the first step in making the menu role-orientated instead of functionality-oriented. The look and feel of the new menu was very similar to Outlook, bringing NAV closer to other Microsoft products.
The three-tier architecture appeared with the release of Dynamics NAV 2009, along with the RTC client, the new Page object, designing Report layouts on Visual Studio, and Web Services. The old client was renamed and called the Classic client. In Dynamics NAV 2013 the Classic client disappears, but this release includes the new Web client and the SharePoint client.
For existing customers, upgrading to NAV 2009 with the new RTC client was a huge effort. This is why many companies chose to do a technical upgrade – to take advantage of the new Web Services interface. But they used the Classic client and therefore did not move to the full three-tier architecture.
And finally Dynamics NAV 2013 has been released, and this is what the book is all about.