Table objects are the foundation of every NAV application. Every project should start by designing the tables. Tables contain the definitions of the data structures, the data relationships within and between the tables, as well as many of the data constraints and validations.

The coded logic in a table triggers not only provides the basic control for the insertion, modification, and deletion of records, but also embodies many of the business rules for an application. Such logic isn't just at the record level but also at the field level. When we embed a large part of the application data handling logic within the tables, it makes the application easier to develop, debug, support, modify, and upgrade.

Let's create a simple Donor table for our NAV Donor application. First, we will inspect existing definitions for tables containing name and address information. Basic inspection is done by clicking on the Tables button in the Object Designer, then highlighting the desired table and clicking the Design button. Good examples are the Customer table (table object 18) and the Vendor table (table object 23).

We see some field name and definition patterns that we will generally copy on the basis of "consistency is good". One exception to the copying will be the Primary Key field. In the other tables, that field is No., but we will use Donor ID, just to make all our examples stand out from views of standard code.

The Donor table will contain the following data fields:

In the preceding data field list, three of the fields are defined as Code fields, rather than Text fields. This is because these will be referenced by or will reference to other data tables. Using Code fields limits the contents to a subset of the ASCII character set, making it easier to constrain entries to a range of values. Code fields will be discussed in more detail in Chapter 3, Data Types and Fields for Data Storage and Processing.

The Donor ID will be a unique identifier for our Donor record as it will also be referenced by other subordinate tables. The Post Code and Country/Region Code will reference other existing tables for validation. We choose the name, size, and data definition of these last two fields based on inspecting the equivalent field definitions in the Customer and Vendor tables.

We will have to design and define any referenced validation tables before we can eventually complete the definition of the Donor table. But our goal at the moment is just to get started.

Open the Object Designer, click on Table (in the left column of buttons) and click on New (in the bottom row of buttons). Enter the first field name (Donor ID) in the Field Name column and then enter the data type in the Data Type column. For those data types where length is appropriate, enter the maximum length in the Length column (for example text fields require lengths, date or numeric fields do not). Enter Description data as desired; these are only for display here as internal documentation.

As you can see in the following screenshot (and will have noticed already if you are following along in your system), when you enter a Text data type, the field length will default to 30 characters. This is simply an 'ease-of-use' default, which you should override as appropriate for your design. The 30 character Text default and 10 character Code default are used because this matches many standard application data fields of those data types.

The question often arises as to what field numbering scheme to use. Various systems follow a variety of standard practices, but in NAV, when you are creating a new table from scratch, it is a good idea to increment the Field No. by 10, as you can see in the preceding screenshot. The default increment for Field No. is 1. For a group of fields (such as an address block) where you are certain you will never add any intervening fields, you could leave the increment at 1, but there is no cost for using the larger increment.

The numeric sequence of fields determines the default sequence in which data fields will display in a wide variety of situations, especially in the Classic Client. An example would be the order of the fields in any list presented to the user for setting up data filters in the Classic Client. This default sequence can only be changed by renumbering the fields. The compiler references each field by its Field No. not by its Field Name, so the renumbering of fields can be difficult once you have created other routines that reference back to these fields. At that point, it is generally better to simply add new fields where you can fit them without any renumbering.

In fact, it can be irritatingly painful to renumber fields at any point after a table has been defined and saved. In addition to the field numbers controlling the sequence of presentation of fields, the field numbers control bulk data transfer (those transfers that operate at the record level rather than explicitly field to field transfer—for example the TRANSFERFIELD instruction). In a record-level transfer, data is transferred from each field in the source record to the field of the same number in the target record.

Obviously, it's a good idea to define an overall standard for field numbering as you start. Doing so makes it easier to plan your field numbering scheme for each table. Your design will be clearer for you and your user, if you are methodical about your design planning before you begin writing code (try to avoid the Ready-Fire-Aim school of system development). The increment of Field No. by 10 allows you to insert new fields in their logical sequence as the design matures. While it is not required to have the data fields appear in any particular order, it is frequently convenient for testing and often clarifies some of the user interactions.

When you have completed this first table, your definition should look like the following screenshot:

At this point, you can exit and save your Donor Table. The easiest way to do this is to simply press Esc until you are asked to save your changes.

When you respond by clicking on Yes, you will be asked for the object number and name you wish to assign. In a normal development situation, you will plan ahead what Object Number and descriptive Object Name you want to use.

In this case, we will use table Object No. 50000 and name it Donor. We are using 50000 as our Table Number just because it is the first (lowest) number available to us for a custom table through our Table Designer granule license.

Note that NAV likes to compile any object as it is saved, so the Compiled option is automatically checked. A compiled object is one that can be executed. If the object we were working on was not ready to be compiled without error, we could unselect the Compiled option in the Save As window, as shown in the preceding screenshot.

Pages are for the Role Tailored Client. Forms are for the Classic Client. If you are in the challenging position of maintaining a dual personality system (that is, running both clients), you will be forced to maintain equivalent versions of both Pages and Forms. We aren't going to address that situation in depth in this book as we are not going to cover the design and development of Forms in detail. In this book, we will focus on Pages and cover Forms just enough so that you can create a few to use as maintenance and debugging tools.

Pages fulfill several basic purposes. They provide views of data or processes designed for on-screen display only. They provide key points of user data entry into the system. They also act as containers for action items (menu options). The first page with which a user will come in contact is a Role Center Page. The Role Center Page provides the user with a view of work tasks to be done. The Role Center Page should be tailored to the job duties of each user, so there will be a variety of Role Center Page formats for any firm.

There are several basic types of display/entry pages in NAV:

There are also page parts (they look and program like a page, but don't stand alone) as well as user interfaces that appear as pages, but are not Page objects. The latter user interfaces are generated by various dialog functions.

List pages

List pages display a simple list of any number of records in a single table. The Customer List page in the following screenshot shows a subset of the data for each customer displayed. The Master record list shows fields intended to make it easy to find a specific entry. List pages/forms often do not allow entry or editing of the data. Journal/Worksheet pages look like List pages, but are intended for data entry.

Card pages

Card pages display one record at a time. These are generally used for the entry or display of individual table records. Examples of frequently accessed card pages include Customer Card for customer data, Item Card for inventory items, and G/L Account Card for general ledger accounts.

Card pages often have FastTabs (multiple pages with each tab focusing on a different set of related customer data). FastTabs can be expanded or collapsed dynamically, allowing the specific data visible at any time to be controlled by the user.

Card pages for Master records display all the required data entry fields. Typically, they also display summary data about related activity so that the Card page can be used as the primary inquiry point for Master records. The following screenshot is a sample of a standard Customer Card:

Document pages

Another page style within NAV consists of what looks like a Card page plus a List page. An example is the Sales Order page as shown in the following screenshot. In this example, the upper portion of the page is in the style of a Card page with several tabs showing Sales Order data fields that have a single occurrence on the page (in other words, do not occur in a repeating column). The lower portion of the Document page is in the style of a List page showing a list of all the line items on the Sales Order (all fields are in repeating columns).

Line items may include product to be shipped, special charges, comments, and other pertinent order details. The information to the right of the data entry is related data and computations that have been retrieved and formatted. On top of the page, the information is for the Ordering customer and the bottom right contains information for the item on the selected line.

Journal/Worksheet pages

Journal and Worksheet pages look very much like List pages. They display a list of records in the body of the page. Many have a section at the bottom that shows details about the selected line and/or totals for the displayed data. These pages may also include a Filter pane and perhaps a FactBox. The biggest difference between Journal/Worksheet pages and basic List pages is that Journal and Worksheet pages are designed to be used for data entry. An example of a Worksheet page, the Requisition Worksheet in Purchasing, is shown in the following screenshot. This Worksheet assists the user in determining and defining what purchases should be made.

Creating a Card page

Let us try creating a Card page and a List page for the table we created earlier. The NAV IDE contains object generation tools (Wizards) to help you create relatively fully formed Classic Client forms and reports. Creating pages and reports for the Role Tailored Client is less about Wizards and more about actually using the Designer tools, but the Wizards are still very useful.

Open the Object Designer, click on Page and then click on New. The Page Wizard's screen will appear. Enter the name (Donor) or number (50000) of the Table with which the page is to be associated (bound). Choose the option Create a page using a wizard:. Choose Card as shown in the following screenshot. Click on OK.

Next, you will encounter the following Card Page Wizard screen:

As this is our first Page creation effort, we will keep it simple. We will accept the single suggested FastTab of General and click on Next to proceed. That will take us to the following screen.

Now it's time to add all the data fields for our Donor table to the page. Click on the button shown in the following image. That will move all of the Available Fields to the Field Order window.

Now click on the Finish button. The Page wizard will close and you will be looking at the Page Designer form showing the generated page code, as shown in the following screenshot.

Place your cursor on the first blank line at the bottom of the list of control definitions. Right-click and select Properties to open the Page-Properties screen as shown below (you could also press Shift + F4 or click on the Properties icon at the top of the screen). Type the page name to be displayed "Donor Card" into the Caption field, it will default into the MLCaption field too, as follows:

Escape from that screen, and Escape from the Page Designer screen.

A Save Changes form will be displayed, just like the one we saw when we finished defining our Donor table. We have the same task now as we did then, to assign an ID (object number) and Name. Let's make this Page number 50000 and call it Donor Card. Leave the Compiled checkbox checked and click on OK so that the Page will be compiled (and error checked). Assuming you haven't received any error messages, you have now created your first NAV 2009 page object. Congratulations!

If you are doing your work with the original release of NAV 2009, you have to test a new card page by running it from the system Run option. From the Start menu, select Run. In the command box, enter the following:

Dynamicsnav:////runpage?page=50000

If you are using NAV 2009 SP1 or later, you can test your page by simply highlighting it and clicking on the Run button at the bottom of the Object Designer screen (the Run button is programmed to automatically submit that long command to the system).

This will invoke the Role Tailored Client, open it up, and call up your new page 50000. You should see a screen that looks like this.

Experiment a little. Expand the card page to full screen. Enter some Donor data for two or three donors (hint: click on the Actions icon at the top of the page and choose the New option). You might want to open the page with the Page Designer using the Design button, add one of the data fields so it will appear a second time on the card. This time, change the Caption field for that data item. Save and compile. Run a test. Before you quit experimenting, go back and remove any extras that you had added, so that later your Donor Card will be what we created initially.

You could create a second copy of the page so that you could experiment, then discard it later. First, open Page 50000 in Design mode. Then click on File | Save As and save the page object as Page number 50090 with a different name such as Test Donor Card. Compile it, then make whatever changes you want, deleting the experimental page when you are done experimenting.

When you begin testing, you will find that a lot of features have been created automatically as part of the Card page, but you are still very limited in what you can do. For example, without a properly set up List Page, it's harder to move around in your table and quickly find different Donors, especially if there are more than just a few records in the table. This difficulty would be even more significant for your users. That's why List pages are the primary data navigation interface in the application system. So let's create a List page for our Donor table.

Creating a List page

The process of creating a Donor List page is essentially the same as the one we just went through for the Donor Card page. Open the Object Designer, click on Page, and then click on New. The Page Wizard's first screen will appear. Enter the name (Donor) or number (50000) of the table with which you want the page to be associated. Choose the option Create a page using a wizard:. Choose List and click on OK.

You will see a List Page Wizard form that looks just like the second screen you encountered when you were creating a Card page. Unlike the Card page, we will use the single field selection button (>) to choose just the four individual fields we want to appear in our List page. The image below shows which fields to choose.

Now click on the Finish button. The Page wizard will close and you will be looking at the Page Designer form showing the generated material.

Place your cursor on the first blank line at the bottom of the list of fields, right-click, then select Properties. Type the page name to be displayed "Donor List" in the Caption field, it will default into the MLCaption field too. In that same property list, in the CardFormID field, enter the name (or ID number) of the Card page that should be used to display any entry that will be displayed on this List page. In this case, that will be Donor Card.

After you've made your property entries, the Page Properties form will look like the following screenshot:

In the Classic Client, the Card form is the first point of contact with the information in a table. When you invoke the List form from the Card form, a property on the table determines what List form is activated. In the RTC, the List page is the first point of contact with the information in a table. When you invoke the Card page from the List page, the CardFormID property determines what Card page to activate.

We can always return to the created page in the Page Designer and easily add fields we left off or remove something we decide is not needed. In addition, NAV list pages include a feature that allows you to have some field columns with the Visible property set to FALSE initially. This property is field specific, controls whether the column for a data field displays on screen or not, and can be personalized by users.

In order to save and compile the new page, just press Esc key and respond with Yes to the Save Changes form. Enter the Page number (ID) you want to assign (use 50001) and name (use Donor List). If you reused the Page object number 50000, you would have overwritten the Card page you created earlier.

At this point, we have a data structure (Table 50000—Donor), a page to enter and maintain data, (Page 50000—Donor Card) and a page to display or inquire into a list of data (Page 50001—Donor List). Let us use our Donor List and Donor Card to enter some data into our table, edit it, and review it.

In a full application, we would be accessing our pages from a Role Center page. But for now, we will just test our pages directly through the Run option. This will invoke the Role Tailored Client, open it up and call up page 50001. You should see a screen that looks like this:

Notice the New command icon that has been included on the Action pane for your new page. That was provided automatically, without you needing to code it. Very convenient. Click on New. Your Donor Card page will open up in Add mode. Now is a good time to create some elementary test data. Enter the data for a Donor. Click on OK. Your new Donor record is displayed in the Donor List page. Hopefully you're having a good time, after all, success is enjoyable, even in small amounts.

Click on New again. Enter another Donor test record. This time, instead of clicking on the OK button, click on the option symbol (the inverted triangle) at the right of the button. You will see that you have two entry completion options.

If you simply click on OK or you press Ctrl + Enter, the control will return to the list page. But if you click on the OK & New option, the record just entered will be saved and you will return to an empty New Card page ready for the next record to be entered. Obviously, this second option is handy for situations requiring repetitive data entry.

After you have entered two or three Donor entries, go back to the Donor List page. Highlight one of the Donor entries, then double-click it. You will end up back in the Donor Card page in Edit mode with the highlighted Donor record loaded, ready to be changed. Change it and then click on OK. You return to the Donor List page with the Donor record updated with your changes similar to what's shown in the following screenshot:

Before we move on to creating a simple report, let's take a quick look at the list of keyboard shortcuts that are available in NAV 2009. From the RTC, call up Microsoft Dynamics Help. Use Search to find Keyboard Shortcuts. This will give you a list of the many keyboard shortcuts that are available within the Role Tailored Client.

Change focus to the Classic Client, where you've been doing your development work. Access the Help menu option in the header. Choose Overview of F Keys. This will display a list of the common keyboard shortcuts used within the Classic Client. You will see that this list of shortcuts is totally different from the one in the RTC (and much shorter). This is because there was a Microsoft product management decision to have NAV keyboard shortcuts more like those in Microsoft Excel. You have the challenge of remembering two sets of shortcuts in the same system and using the right ones at the right time.

Hopefully, you are beginning to get a feeling for the ease of use and power of C/SIDE and NAV. Let's return to the Object Designer in the Classic Client. You've been viewing the Donors through the normal pages in the same manner as would a user, through the application Pages. As you have access to the Object Designer, you can also inspect, even manipulate data directly within the table. Simply access the Table Designer again, highlight the Donor table (50000) and Run the table.

Running a table creates a default Classic Client form that includes all the displayable fields in the table. Now you can see the same Donor records you just entered. Dependent on the specific design of the table (about which you will learn more in subsequent chapters), you can freely modify the contents of the table.

Report objects can be used for several purposes, sometimes more than one purpose at a time. One purpose is the display of data. This can be on-screen (called Preview mode) or output to a printer device driver (Print mode). The displayed data may be read from the database, or may be the result of significant processing. As you would expect, a report may be extracting data from a single table (for example, a list of customers) or a combination of several tables (for example, a sales analysis report).

Other report objects have the purpose of only processing data, without any display formatted output of the processed results. Typically, such reports are referred to as batch processing reports. Reports can also be used as containers for program logic to be called from other objects or executed as an intermediate step in some sequence of processes. Normally, this task would be handled by Codeunit objects, but you can also use report objects if you want to.

Report formats are limited to a combination of your imagination, your budget, and the capabilities of NAV reporting. NAV reporting is very powerful and flexible in terms of what data can be reported, plus the various types of filtering and combining can be done. In the Classic Client, NAV reporting is relatively limited in terms of formatting. However, reports designed to be run in the Role Tailored Client use RDLC capabilities similar to those available from SQL Server Reporting Services. Consequently, they have a great deal of flexibility.

One standard way to create a new Role Tailored Client report is to create a report for the Classic Client, and then "transform" it (an embedded process that converts an object for the RTC) and then reformat it for the RTC. It may seem a roundabout method, but, depending on the report, it's sometimes the easiest approach. If it so happens that you prefer to only create the report in the Classic Client format, the RTC will run that one too, but without any of the new RTC report features.

Common report formats in NAV (both clients) include document style (for example Invoices or Purchase Orders), list style (for example, Customer List, Inventory Item List, Aged Accounts Receivable), and label format style (for example, a page of name and address labels). There is only one Report object. It can contain formatting layout information for only the Classic Client or for both the Classic and Role Tailored Clients. From a practical point of view, if you are going to run a report only from the RTC, the Classic Client format information can be very minimal (that is not particularly useful for Classic Client reporting).

A significant aspect of the NAV report object is the built-in "read-then-process" looping structure, which automates the sequence of "read a record, process the record, then read the next record". When manually creating or enhancing reports, you can define one data structure as subordinate to another, thus creating nested read-then-process loops. This type of predefined structure has its good points and bad points. The good points usually relate to how easy it is to do the kind of things it is designed for and the bad points relate to how hard it is to do something that the structure doesn't anticipate. We will cover both sides of discussion when we cover Reports in detail in Chapter 5, Reports.

We've taken a quick look at normal RTC data entry and viewing and we've looked at how the data is defined in the table. We will now look at how that data might be extracted and reported.

First, we will create a simple list format report based on our Donor table. We will use the Report Wizard. The Report Wizard is quite useful for simple reports. The Report Wizard and Report Designer tools are available to anyone who has a license containing the Report Designer granule.

When you are doing more complex reports, it is often only modestly helpful to start with the Report Wizard. For one thing, the Report Wizard only deals with a single input table. However, even with complex reports, sometimes it is a good idea to create a limited test version of some aspect of a larger report. Then you may create your full report without use of the Wizard, but using the Report Wizard generated code as your model for some aspect of layout or group totaling.

Open the Object Designer, click on Report, and then click on New. The Report Wizard's first screen will appear. Enter the name (Donor) or number (50000) of the table with which you want the report to be associated. Choose the option Create a report using a wizard. This time choose a Tabular-Type Report Wizard to create a Donor List. Then click on OK, as shown in the following screenshot:

Next, you will be presented with the window shown in the following screenshot for choosing what data fields you want on your report. This is very much like what we saw earlier in the Page Wizard. The order in which you place the fields in the Field Order column, top to bottom (as shown in the following screenshot), will be the order in which they appear on your report, left to right.

You can preview your report in the Classic report viewer during the process of its creation, to see if you are getting the layout you want. Often you will perform quite a bit of manual formatting after you finish with the Wizard. As the report preview function utilizes the driver for the current default printer for formatting, make sure you have a default printer active and available before you attempt to preview an NAV report.

After you have chosen the fields you want on your report (some are suggested in the preceding screenshot), click on Next. This will bring up a screen allowing you to predefine a processing/printing sequence for this report. You can select from any of the defined keys. At the moment our Donor table only has one key so let's choose the No, I don't want a special sorting of my data. As you will see later, that will generate a report where you can choose the sort sequence for each run. Click on Next.

Now you can choose a List Style or a Document Style layout. Click on each one of them to get an idea of the difference. If you like, Preview the report in process for each of these options chosen. Note that when you Run a report (and previewing it, is running it), the first thing you see is called the Report request screen. A default Report request screen from the Donor List report would look like the following screenshot:

The Report request screen is where the user enters any variable information, data filters, page, printer setups, and desired sort order to control each report run. If no key is selected for the report, the Sort button will appear at the bottom right of the screen. This allows the user to choose which data key will apply to a report run. The user can also choose to Print the report (output to a physical device or PDF file) or Preview it (output to the screen). To start with, just click on Preview to see your current layout.

Once you are satisfied with the layout, click on Finish. You will now be in the Report Designer, ready to make manual changes. Exit the Report Designer by pressing the close-window icon, saying Yes, you do want to save changes. Save your new report as ID 50000 and Name "Donor List". Run your new report, using the Object Designer Run button. It should look much like the following:

Our next step is to transform the Classic Client report layout into an RTC (RDLC) report layout. Highlight Report 5000 and click on Design. Then click on Tools | Create Layout Suggestion (see the following screenshot).

Your system will whirr and hum and buzz and a display similar to the following will appear:

You have been transported along with your transformed report layout into the Microsoft Visual Studio Report Layout tool. This tool gives you access to a considerable variety of graphical effects, interactive reporting functions, and other capabilities. We will explore these in detail in Chapter 5, Reports.

While you could make many different changes to this layout, for now just exit Visual Studio via the Esc key. As you exit Visual Studio, you will be presented with the following question on screen:

Click on Yes, which will take you back to the Classic Report Designer. Exit from the Report Designer, saving your revised report the same way you saved the original earlier.

By the way, if you had made changes to your layout and saved them, then later invoked the Create Layout Suggestion again, that would overwrite your layout, changes, and all. After the first time, access to this tool for a report should be via View | Layout.

In order to test the new RTC version of the Donor List report, simply highlight the report line in the Object Designer and click on Run. The RTC Report Request Screen will display, looking like the following screenshot:

Preview the report. It should look very similar to the following screenshot:

As you can see, the Classic Client report and the RTC report look similar, but not the same. The goal with the new client was not to replicate the old client, but to provide similar functionality so that almost all capabilities were retained, but with many new capabilities being available.

There is a lot more to learn about the design, creation, modification, and control of Reports. All we have done so far is scratch the surface. But if you're following along in your own system, especially if you've done a little experimenting of your own along the way, you now have a pretty good overview of what it feels like to begin developing in NAV 2009.

We are done with our introduction to development for now. We will continue with our introductory review of NAV's object types.