As you know, design of an application starts with the data. The data design depends on the types of data that your development tool set allows you to use. Since NAV is designed specifically to develop financially oriented business applications, the NAV data types are financially and business oriented, and also have some special features that make it easier to design and develop typical business applications. Furthermore, these same special features can make your applications run faster.

In this article, we will cover the data types that you are most likely to use. We will also take an overview of the others. In addition, we will also cover field classes, which are where the special features are enabled.

Fields

A field is the basic element of data definition in NAV—the "atom" in the structure of a system. The mechanical definition of a field consists of its number, its description (name), and its data type (and, of course, any parameters required for its particular data type). From a logical point of view, a field is also defined by its Properties and the C/AL code contained in its Triggers.

Field Properties

The specific properties that can be defined for a field partially depend on the data type. First we will review the universal field properties. Then we will review the properties that are data-type dependent plus some other field properties. You can check out the remaining properties by using Help within the Table Designer.Fields

You can access the properties of a field while viewing the table in Design mode, by highlighting the field line whose properties you wish to examine and clicking on the Properties icon or pressing Shift + F4. All the property screenshots in this section are obtained in this way for fields within the standard Customer table. As we review various field properties, you will learn more if, using the Object Designer, you follow along in your NAV system. Poke around and explore different properties and the values they can have. Use the Field Help function liberally and read the help for various properties.

The property value enclosed in < > (less than sign, greater than sign), is the default value for that property. When you set a property to any other value, < and > should not be present unless they are supposed to be the part of the property value (e.g. part of a Text string value).All data types have the following properties:

The following screenshot shows the BLOB properties for the Picture Field in the Customer table:

This set of properties, for fields of the BLOB data type, is the simplest set of field properties. After the properties that are shared by all data types, appear the BLOB-specific properties—SubType and Owner:

  
1. SubType: This defines the type of data stored in the BLOB. The three  sub-type choices are Bitmap (for bitmap graphics), Memo (for text data), and  User-Defined (for anything else). User-Defined is the default value.

  

2. Owner: The usage is not defined.

 

The available properties of Code and Text fields are quite similar to one another. The following are some common properties between the two as shown in the screenshot overleaf:

 
• DataLength: This specifies how many characters long the data field is.
• InitValue: This is the value that the system should supply as a default when  the system actively initializes the field.
• AltSearchField: This allows definition of an alternative field in the same  table to be searched for a match if no match is found on a lookup on this datastyle="width: 761px; height: 446px;"  item. For example, you might want to allow customers to be looked up eitherstyle="width: 761px; height: 446px;"  by their Customer No. or by their Phone No. In that case, in the No. field  properties you would supply the Phone No. field name in the AltSearchField  field. Then, when a user searches in the No. field, NAV will first look for  a match in the No. field and, if it is not found there, it will then search  the Phone No. field for a match. Use of this property can save you a lot of  coding, but make sure both fields have high placement in a key so the lookup  will be speedy.
• Editable: This is set to No when you don't want to allow a field to ever be  edited for example, if this is a computed or assigned value field that the user  should not change.
• NotBlank, Numeric, CharAllowed, DateFormula, and ValuesAllowed: All  these support placing constraints on the specific data that can be entered into  this field.
• TableRelation and ValidateTableRelation: These are used to  control referencing and validation of entries against another table.  (TestTableRelation is an infrequently used property, which controls whether  or not this relationship should be tested during a database validation test.)

Let us take a look at the properties of couple more Data types, Integer and Decimal. You may find it useful to explore them on your own as well. Specific properties related to the basic numeric content of these data types are as follows and are also shown in the following screenshot:

• DecimalPlaces: This sets the number of decimal places in a Decimal  data item.
• BlankNumbers, BlankZero, and SignDisplacement: All these can be used to  influence the formatting and display of the data in the field.
• MinValue and MaxValue: These can constrain the range of data values allowed.
• AutoIncrement: This allows setting up of one field in a table to automatically  increment for each record entered. This is almost always used to support  automatic updating of a field used as the last field in a primary key, enabling  creation of a unique key.

The field properties for an Integer field with a FieldClass property of FlowField are similar to those of a field with a FieldClass property of Normal. The differencesstyle="width: 761px; height: 446px;"relate to the fact that the field does not actually contain data but holds the formula by which the displayed value is calculated, as shown in the following screenshot overleaf.

Note the presence of the CalcFormula property and the absence of the AltSearchField, AutoIncrement, and TestTableRelation properties. Similar differences exist for FlowFields of other data types.

The properties for an Option data type, whose properties are shown in the following screenshot, are essentially like those of the other numeric data types, but with a datatype-specific set of properties as described below:

• OptionString: This spells out the text interpretations for the stored integer  values contained in Option data type fields.
• OptionCaption and OptionCaptionML: These serve the same captioning  and multi-language purposes as other caption properties.

The properties defined for FlowFilter fields, such as Date Filter in the following screenshot overleaf, are similar to those of Normal data fields. Take a look at the Date Filter field (a Date FlowFilter field) and the Global Dimension 1 Filter field (a Code FlowFilter field) in the Customer table. The Date Filter field property looks similar to a Normal FieldClass field.