We have identified that each Microsoft Dynamics NAV system has lots of objects that control the information the system stores and how that information is processed and displayed. These are broken into different types each of which has a specific purpose.
Tables
Control what information is stored by your Dynamics NAV system and its structure. It’s the filing system of your ERP system. Think of the database as the draw in your cabinet (your SQL server is the cabinet itself) and each table as a file. In that file you have sheets of forms or what we call records of information and on each form you have boxes or what we call fields. The table definition defines each file and box, all the sheets in a file have to have the same format form but maybe you don’t fill all of it in.
Pages
Pages are objects that form how a set of information is displayed on screen. A Screen in Dynamics NAV is actually made up of several pages with a page maybe displaying a list and then other pages displaying more information depending on the record you point to I. The list. Pages don’t define the exact layout grid reference style as they are designed to be display independent. That means they will display correctly on your mouse driven windows client but also differently and more useable on your touch screen tablet and differently again on the small screen on your phone (when Dynamics NV 2016 get here for the phone).
For those with older Classic versions of NAV, pages have replaced forms and one of the major tasks to upgrade is to recreate your customised forms as pages.
Reports
Pretty obviously these define what the reports that come out of your system look like. There can be extensive scripting logic in C/side behind the report to draw together the required data, and sort or filter it in the required way. Then the report sections point to these either derived or actual table records. When a report is run this logic is executed and the resulting ‘data’ is created by executing and compiling that logic in hopefully a summarised way one the middle tier as close to the database to be as fast as possible.
That report ‘data’ is then passed to a price of software called the Microsoft’s SQL Report Viewer running on whatever client you are using. That report viewer then ‘renders’ that data into the report you see on screen depending on the option you have chosen. As part of the report object the system holds what we call the Report Design Language (RDL) layout definition, which is created and uploaded to the report.
The only exception to this is it’s defined to run as a ‘word’ report in which case the appropriate word template is extracted from the database and used for the merge instead.
The new RDL layouts are the biggest single task on upgrade from 2009 and earlier system as all the reports have to be started again!
XML Ports
So these can be used to export or import information to Dynamics NAV. That information can either be in XML (the best most modern reliable format) or fixed or variable length text files. This is the object you can use to import or export to CSV files! There are a lot less of these as standard in a Dynamics NAV system, really there to be used if you need any import or export capability.
Note for you 2009 and before users, XML Ports have replaced dataports, and yes, I’m afraid they do all have to be redone as part of an upgrade process.
Code Units
These hold the logic, procedures, processes or instructions for what the system does. There are functions that can be executed when you press enter on a field, press a toolbar icon or start a process from the job queue. They lookup and update different tables and may start either pages or reports display the results. They are the core of your system and the most important objects after tables (nothing beats the data structure for importance).
Querys
A new object type for the 2013 version, they allow retrieval of data from across multiple tables in the SQL database in an especially efficient way. Rather than having to send a request to the server for one record and then another for the related records in another table (customers and that customers outstanding ledger entries for instance) before going on to the next record, it can just send the one request and received the whole set of data back in one go.
This makes the process much faster and puts less load on the system. Especially import is that Query’s can be queried from Excel using the Internet compliant OData protocol. A great way to extract a whole set of data without having an impact elsewhere.
Menusets
Simply put they define the options on the departments page in Dynamics NAV. When new pages or functionality is created it often needs adding to a menusuite.
Hopefully you now understand the critically important role that objects play in building your NAV solution and what each type is for.
Note
This post is part of a 6-part series. A link to all the posts in this series are below;
- Why Do You Need to Understand the Technical Structure of Dynamics NAV
- Part 1: Clients & Servers, Executables and Objects & Databases in Dynamics NAV
- Part 2: Object Types, Tables, Pages, Reports, XML Data, Code Units, Query Object Types and Menusets in Dynamics NAV
- Part 3: Object Numbers, Object Licensing in Dynamics NAV
- Part 4: Web Services – interface method of Choice in Dynamics NAV
- Part 5: Companies and Per Company or Per Database Tables in Dynamics NAV
- Part 6: Multi-tenancy – What Does it mean?