Basic Objects in Microsoft Dynamics NAV

There are eight basic objects available in Microsoft Dynamics NAV 2009.

·         Tables

·         Forms

·         Pages

·         Reports

·         Dataports

·         XMLports

·         Codeunits

·         MenuSuites

Tables: Used to describe how data is stored in the database and how it is retrieved. Understanding tables is the key to using all of the other objects in C/SIDE. 

Forms: Used to display data to users in the Microsoft Dynamics NAV Classic client. Forms allow users to add records to a table, and to view and modify records. 

Pages: Used to display data to users in the Microsoft Dynamics NAV RoleTailored client. Pages allow users to add records to a table, and to view and modify records. 

Reports: Used to summarize and print detailed information by using filters and sorting, which are selected by the users. 

Dataports: Used to export or import table data in text format. Not supported in the RoleTailored client. 

XMLports: Used to export or import table data in XML format. In the RoleTailored client, XMLports replace Dataports as a means to export and import data, even in text format. 

Codeunits: Used to organize and group code which is written by the developers. 

MenuSuites: Used to contain menus that are displayed in the Navigation Pane in the Classic client and the Departments page in the RoleTailored client.

 

Use the…	When working on…
Table Designer	Tables
Form Designer	Forms
Page Designer	Pages
Report Designer	Reports
Dataport Designer	Dataports
XMLport Designer	XMLports
C/AL Editor	Codeunits
Navigation Pane Designer	MenuSuites

 General C/SIDE Concepts

The eight application object types are based on some general concepts. Some of these concepts are restricted to one type of application object whereas others apply to several types. 

The following table summarizes how the application objects are related to these general concepts and explains for what each type of application object is used.

 

Application              Object Type	Uses	Uses Concepts
Table	A table is used for storing the actual data. Typically a business application has a Customer table that stores information such as name, address, phone number, and contact person for each customer.	Properties, Fields, Field Groups, Keys, C/AL, Triggers
Form	A form is used to access the information contained in tables in the Classic client. Forms are used when users enter new  information and when they view existing information.	Properties, C/AL, Controls, Triggers
Page	A page is used to access the information contained in tables in the RoleTailored client. Pages are used when users enter new information and when they view existing information.	Properties, C/AL, Controls, Triggers
Report	A report is used to present data that contains summary information. For example, use a report to print a list of customers.	Properties, C/AL, DataItems, Sections, Controls, Triggers, RequestForm, RequestPage, Client Report Definition ( RDLC) report layout.
Dataport	A dataport is used to import and export information to and from other programs in a text format (for example, a commaseparated text file). Dataports are used only in the Classic client.	Properties, C/AL, DataItems, RequestForm, Triggers
XMLport	An XMLport is used to import and export information to and from other programs in an XML format. XMLports simplify and streamline the process of exchanging data in XML documents. In the RoleTailored client, XMLports are also used to import and export information in a text format.	Properties, C/AL, NodeNames, NodeTypes, XMLport Events, RequestPage
Codeunit	A codeunit contains user-defined functions written in C/AL code. These functions can be used from the other objects in the application. This minimizes the size of the application because the same code can be reused.	C/AL, Triggers
MenuSuite	A MenuSuite contains the menus displayed in the Navigation Pane and in the Departments Page.	Menu Node, Menu Group, Menu Item

 Terminologies

The following shows descriptions of several terms in the third column: 

Properties: Properties control the appearance and behavior of application objects and all sub-objects. Properties are used to control the appearance of data, specify default values, specify colors, and define relationships.

C/AL: C/AL is the language used for writing functions in C/SIDE. In the previous table, C/AL refers to functions written in this language. 

Triggers: When specific things happen to the application objects, the system automatically activates a trigger. Inside a trigger, developers can add C/AL code if they want to modify the default behavior of the application object or extend its functionality. 

Fields: A field is the smallest unit of information in the database. A field typically stores information such as a name or a number. 

Keys: A key defines the order in which data is stored in the tables. Speed up searches in tables by defining several keys to sort information in different ways. 

Controls: Controls are objects on a form or report that display data, perform actions or decorate the form. Typical examples are command buttons and text labels. 

Request Form: A request form is a form used in a report or a dataport. Before a report or a dataport is run, a request form appears to let the user specify filters and options for the report or the dataport.

Request Page: A request page is the request form equivalent in the RoleTailored client.

Data Items: A data item is a building block used for defining a model of data when creating a report or a dataport. By using a hierarchy of data items, developers define which data to include in the report. A data item represents a table and when a report is run, the system cycles through the records in the associated table. In a report, a data item can have one or more sections. 

Sections: A section is a substructure of a data item. A section is where controls are placed to display information. Generally, sections are used to define the body, header, and footer in the report. 

NodeName: NodeNames are used to specify the name of a node in an XML document. The name specified is inserted in the NodeName field of the XMLport Designer of the element or attribute in question. 

NodeTypes: This property is used to specify whether an XML object is an element or an attribute.

Menu Node: A Menu Node can be either a Menu Group or a Menu Item.

Menu Group: A Menu Group is a collection of Menu Nodes.

Menu Item: A Menu Item is the lowest level of the menu tree. It is associated with a specific application object.

 

 

 

Installing a NAV 2009 Classic client

1.       Open the backup of Microsoft Dynamics nav .

2.       Double click the Setup file. The below window will open.

                  Starting with the startup screen of the installation disk, Click on C/SIDE Client for Microsoft Dynamics NAV under the Install section of the screen to run the installation wizard.

                   The installation process takes us through the setup wizard. In a network installation, we would typically select Minimum as the Install option.

Minimum Typically used in a network Invironment. Only with few install options.		Complete All install options selected by default.		Custom Most flexible option and also the one most frequently used. Gives the ability to choose the desired install options.

If we select Custom, we will get a few options to select from the following:

·          Help: This is the option for installing Dynamics NAV Online Help. It is recommended to have this option always on.

·         Demo Database: This is the option to install a demonstration database with the CRONUS company. This is not needed typically in a network installation. We may need to install this option in a single user installation.

·          Backup of Demo Database: If selected, this option will copy a backup (.fbk file) of the demo database to the program folder.

·          Commerce Integration, Employee Portal: These options need to be selected if we are installing Employee Portal, Commerce Gateway, or Commerce portal (discontinued now) components.

·          Business Notification Manager: This is the option to send automatic business event notifications from NAV.

·          Outlook Integration: This feature installs components for Dynamics NAV and Microsoft Outlook Integration. This also installs a toolbar in Microsoft Outlook.

• Gantt Server: The OLAP component that facilitates management of shop floor production using visual status updates and plans.

 

·         Click Next .

 

 

How to install more than one Dynamics NAV 2009 Demo Database

           By default when you are installing the demo database by the installation program you can only install one Demo Database. But if you would like to have more than one Demo Database to try different things in, how to accomplish that? I assume that you know that you can create a new company in the classic client, but you will then not get the demo data. The solution is simple to use SQL Server Management Studio to attach more than one version of the Demo Database.

1.     Open the Run Window Type “Services.msc”. It open the services

2.     Stop the SQL Server service

3.     Make a copy the database files in "C:\Program Files\Microsoft                 Dynamics NAV\60\Database" to new location. For example "C:\NAVTestDB\"

4.     Start the SQL Server service

5.     Start SQL Server Management Studio and connection to the instance  where you have installed the other Demo Database.

6.     Right click on "Databases" and select "Attach" and click "Add". Then pick the database file that you did copy to new location.

7.     Change the "Attach As" column for the new Demo Database file to "NAVDEMO"

8.     Press OK

9.     Update the Microsoft Dynamics NAV server configuration file to use the new database by open "CustomSettings.config" file in notepad. The file is normally located under "C:\Program Files\ Microsoft Dynamics NAV\60\Service".

10.    Locate the DatabaseName key.

11.     Change the value attribute to "NAVDEMO"

 

12.  Open the Run Window Type “Services.msc”.

13.    Restart the "Microsoft Dynamics NAV Server" service in the Windows    Service manager

 

Microsoft Dynamic Nav Reports

Reports Fundamentals

·         Reports structure and print information from a database.

·         Reports print and display documents in the application.

·         The report data is collected and presented on the screen or printed on the paper when the report is run.

·         The report description contains properties, triggers, sections, controls, a request form, a request page and RDL data. The last two components are required for reports that are developed for the RoleTailored client. The following shows components of a report and how they are related:

Properties

A property is an attribute of an object, or its component, that characterizes and specifies behavior of the parent in some ways, such as whether it is visible.

Triggers

Certain predefined events that occur to a report cause the system to execute a user-definable C/AL function. The event and the function together are called a trigger.

Triggers in a report can be divided into six categories:

·         Report triggers

·         Data item triggers

·         Section triggers

·         Request form triggers

·         Request page triggers

·         Control triggers

Report triggers include OnPreReport that contains statements that are executed right before the report is run, and OnPostReport that contains statements that are executed right before the report execution is completed. Triggers in a report are edited in the C/AL Editor.

Data Items

           The data model of a report is built from data items. A data item corresponds to a table. When the report is run, each data item is iterated for all records in the underlying table. When a report is based on more than one table, establish a hierarchy of data items to control how the information is collected by indenting data items.

Sections

Reports can be a printing or nonprinting report. A nonprinting report is used for processing a certain task and does not produce a displayed output. A printing report displays the result in the screen or prints output on the paper.

A section is a visual element of a report. The visual element of a report includes the sections. In a printing report, one or more sections can be attached to each data item. There are several types of sections. Each has a specific function. Usually, the bulk of the data is printed in the Body section of a data item, whereas the Header section of the data item is used to print information before any record of the data item is printed, such as column captions. There can be reports where the Body section is not used at all, and all information is printed in other sections.

Controls

The information that is printed in the sections is made of controls. Controls are also available in the request form and the request page.

Request Form

The request form is the form that is run before the actual report begins execution. It is used to collect requests and options from the user of the report of things such as sort order or level of detail. The request form is run when the report is run in the Classic client.

Types of Printing Reports 

List Reports : A List report prints a list of records from a table.  This data item represents the table being listed. The table is either a Master table or a Supplemental table.

 

Test Reports: A test report is printed from a Journal Table. Its purpose is to test each Journal Line according to certain criteria that are used for posting so that all the errors can be found and fixed before posting. As soon as an error is found during posting, processing stops and the error must be fixed before posting can be tried again.

Posting Reports: A Posting report prints from the Register table. It lists all the transactions (ledger

entries) that are posted into that Register. A Posting report can be printed as part of the Post and Print option in a Journal.

Transaction Reports:

·         It lists all the ledger entries for each record in the Ledger table.

·          It contains a subtotal for each Master table record, and a grand total for all tables printed.

·          It is used to view all transactions for a particular Master record.

·          It has no standard naming convention.