Creating a simple table

To invoke the table designer, open the NAV 2017 Development Environment and the database in which we will be doing our development. In the Object Designer, click on Table (in the left column of buttons) and click New (in the bottom row of buttons). Enter the first field number as 1 (the default is 1), and increment each remaining field number by 10 (the default is 1). Sometimes, it is useful to leave large gaps (such as jumping from 80 to 200 or 500) when the next set of fields have a particular purpose not associated with the prior set of fields.

The fields combining the primary key can use the numbers up to 9 since they are very unlikely to change. If this is changed, there is a substantial amount of refactoring to be done.

NAV 2017 Help says to not leave gaps in field numbers. Based on many years of experience, the authors disagree. Leaving numbering gaps will allow us to later add additional fields between existing fields, if necessary. The result will be data structures that are (at least initially) easier to read and understand. Once a table is referenced by other objects or contains any data, the field numbers of previously defined fields should not be changed.

The following screenshot shows our new table definition in the Table Designer:

Now we can close the table definition (click on File | Save or Ctrl + S or press Esc or close the window - the first two options are the explicit methods of saving our work). We will see a message reminding us to save our changes:

Click on Yes. We must now assign the object number (use 50000) and a unique name (it cannot duplicate the same first 30 characters of another table object in the database). We will name our table Radio Show based on the master record to be stored in the table:

Note that the Compiled option is automatically checked and the Synchronize Schema option is set to Now - with validation, which are the defaults for NAV. Once we press OK and the object is successfully compiled, it is immediately ready to be executed within the application. If the object we were working on was not ready to be compiled without error, we could uncheck the Compiled option in the Save As window.

Uncompiled objects will not be considered by C/SIDE when changes are made to other objects. Be careful. Until we have compiled an object, it is a "work in progress", not an operable routine. There is a Compiled flag on every object that gpes its compilation status. Even when we have compiled an object, we have not confirmed that all is well. We may have made changes that affect other objects which reference the modified object. As a matter of good work habit, we should recompile all objects before we end work for the day.

The Synchronize Schema option choice determines how table changes will be applied to the table data in SQL Server. When the changes are validated, any changes that would be destructpe to existing data will be detected and handled either according to a previously defined upgrade codeunit or by generating an error message. The Synchronize Schema option choices are shown in the following screenshot:

Refer to the documentation (https://msdn.microsoft.com/en-us/dynamics-nav/synchronizing-table-schemas) in the section called Synchronizing Table Schemas for more detail.