Like all database applications, it starts with tables. They contain all the information displayed in a structured way. It is important to understand that the tables of Microsoft Dynamics NAV are not completely normalized. The tables are structured in the way the user interface works. This makes it easy for nontechnical people to understand the data model. We'll discuss the unique structure of the application in Chapter 2, A Sample Application.
Tables, however, not only contain data, but they contain business logic as well. As they are structured like the functionality in the database, tables contain simple functions like address validation and more complex functions for VAT and discount calculation.
Whenever functionality gets more complex or can be shared across the application, it is better to move them to the codeunit object. These are containers of business logic for a special purpose. Tables can also be used as a class without storing data. This allows more structured programming.
For the user interface, there are two object types: reports and pages. Reports are originally intended to be printed on paper but with the current status of technology, they are more and more used as information dashboards, combining management information with drill-through possibilities.
As the tables are structured in the way the application works, the pages are bound to one table. For people new to this concept, it sometimes takes a while to get used to this.
The last object type is an external interface object. XML ports make it possible to import and export data in and out of the system.
Query objects are introduced in Microsoft Dynamics NAV 2013 and allow developers to define SQL Server SELECT statements on the metadata level that can be used in C/AL code. It is possible to join multiple tables into one query. Query objects can also be exposed as OData web services.
For this book, the table and page objects are the most important to understand. Most of this book, however, can also be applied to older versions but then forms should be applied wherever this book addresses pages.
In a traditional development environment, this screen would have a transaction GetJobData and UpdateJobData. These transactions would read the information from the database, map them to the screen, and save the information in the database if the user is finished. However, in Microsoft Dynamics NAV, all fields that are displayed in the interface are stored in one table. This makes it possible for the screen to have built-in triggers to get the data and update the database.
The table object then contains the business logic required for this document. Let's have a look at some of the fields in this table:
When we click on the C/AL Code icon and we focus on currency code, we get the following result:
Currency Code - OnValidate()
IF "Currency Code" <> xRec."Currency Code" THEN
IF NOT JobLedgEntryExist THEN
So the tables in Microsoft Dynamics NAV are not just data containers, they are the foundation for both the business logic and the application workflow.