A field is the basic element of data definition in NAV—the atom in the structure of a system. The elemental definition of a field consists of its number, its description (name), its data type, and, of course, any properties required for its particular data type. A field is defined by the values of its properties and the C/AL code contained in its triggers.
The specific properties that can be defined for a field depend on the data type. There are a minimum set of universal properties. We will review these first. Then, we will review the rest of the more frequently used properties, some that are data dependent and some that are not. You can check out the remaining properties by using Developer and IT Pro Help within the Table Designer.
We can access the properties of a field while viewing the table in Design mode by highlighting the field and then clicking on the Properties icon, or by clicking on Properties under View, or by pressing Shift + F4. All of the property screenshots in this section were obtained this way for fields within the standard Customer table. As we review various field properties, you will learn more if you follow along in your NAV system using the Object Designer. Explore different properties and the values they can have. Make good use of NAV 2015's Help functions liberally for additional information and examples.
The property value that is enclosed within < > (less than and greater than brackets) is the default value for that property. When we set a property to any other value, < > should not be present unless they are supposed to be part of the property value (for example, as part of a text string value). When a property has been changed from its default value, the NAV 2015 C/AL Editor displays the new property value in bold.
All of the fields, of any data type, have the following properties:
The following screenshot shows the properties for the Picture field of the Data Type BLOB in the Company Information table (this field is often used to store a company's logo image):
The set of properties shown for a BLOB data type field is the simplest set of field properties. After the properties that are shared by all of the data types, appear the BLOB-specific properties scan be seen; these are SubType, Owner, and Compressed.
No.
The properties of Code and Text data type fields are quite similar to one another. This is logical, since both represent types of textual data. The following images are from the Customer table:
The following are some properties common to both the Code and Text data types:
No
when we don't want to allow a field to be edited; for example, if it is a computed or assigned value field that the user should not change. Editable defaults to Yes
.Varchar
, Integer
, BigInteger
, and Variant
. Varchar
is the default and causes all of the data to be treated as a text. Integer
and BigInteger
allow only numeric data to be entered. A Variant
can contain any data type from a wide range of NAV data types. In general, once set, this property should not be changed. These settings should not affect any data handling that is done in SQL Server external to NAV, but the conservative approach is not to make changes here.Yes
in order to validate the relation when data is entered or changed. (In other words, confirm that the entered data exists in the target table.) If a TableRelation is defined, and this property is set to No
, the automatic table referential integrity will not be maintained. Note that application code can be written that will bypass this validation.Let's take a look at the properties of two more data types, Decimal and Integer, especially the properties related to numeric content:
2
(2:2), the minimum is 0
, and the maximum is 255
.Yes
, the automatic functionality should not be overridden in code.The properties for an Option data type are similar to those of other numeric data types. This is reasonable because an Option is stored as an integer, but there are also properties that are specific to Option:
Internally, options are stored as integers, which are tied to each option's position in the OptionString starting with position 0, 1, 2, and so on. The OptionString and OptionCaption properties are shown in the following screenshot:
To see field triggers, let us look at our Table 50000 - Radio Show. Open the table in the Design mode, highlight the No. field, press F9, and you will see the following screenshot:
Each field has two triggers, the OnValidate()
trigger and the OnLookup()
trigger, which function as follows:
OnValidate()
: The C/AL code in this trigger is executed whenever an entry is made by the user. Its intended use is to validate that the entry conforms to the design parameters for the field. It can also be executed under program control through the use of the VALIDATE
function (which we will discuss later).OnLookup()
: OnLookup behavior can be triggered by pressing F4 or Shift + F4 from an ellipsis button or by clicking on the lookup arrow in a field, as shown in the following screenshot:OnLookup()
trigger, even a comment line, will eliminate the default behavior of this trigger.Some good examples of tables in the standard product to review for particular features are as follows:
OnValidate
trigger C/AL code, as do all of the primary master tables (Customer, Vendor, Item, Job, and so on.)The number of each field within its parent table object is the unique identifier that NAV uses internally to identify that field. We can easily change a field number when we initially define a table layout. However, after other objects such as pages, reports, or code units reference the fields in a table, it becomes difficult to change the numbers of referenced fields. Deleting a field and reusing its field number for a different purpose is not a good idea and can easily lead to programming confusion.
We cannot easily safely change the definition, renumber, or delete a field that has data present in the database. The same can be said for reducing the defined size of a field to less than the largest size of data that is already present in that field. However, if we force the change, the force function will override the system's built-in safeguards. This action can truncate or delete data.
When we add new fields to standard NAV product tables (those shipped with the product), the new field numbers must be in the 50,000 to 99,999 number range, unless we have been explicitly licensed for another number range. Field numbers for fields in new tables that we create can be anything from 1 to 999,999,999 (in all cases without the commas).
When a field representing the same data element appears in related tables (for example, Table 37 – Sales Line and Table 113 – Sales Invoice Line), the same field number should be assigned to that data element for each of the tables. Not only is this consistent approach easier for reference and maintenance, but it also supports the TRANSFERFIELDS
function. TRANSFERFIELDS
allows you to copy data from one table's record instance to another table's record instance by doing record-to-record mapping based on the field numbers.
If we plan ahead and number the fields logically and consistently from the beginning of our design work and provide an entry in the Description column for each field, we will create code that's easier to maintain. It's a good idea to leave frequent gaps in field number sequences within a table. This allows easier insertion of new fields that are numerically adjacent to related, previously defined fields. In turn, this makes it easier for the following developer to understand the modification's data structure.
For additional information, please see Object Numbering Conventions in the Developer and IT Pro Help in the Development Environment.
In general, the rules for naming fields (data elements in a table) and variables (data elements within the working storage of an object) are the same, and we will discuss them on that basis. The Developer and IT Pro Help section's Naming Conventions describes many recommended best practices for naming within NAV. A lot of additional information can also be found in the recently released C/AL Coding Guidelines at https://community.dynamics.com/nav/w/designpatterns/156.cal-coding-guidelines, which includes a How do I video.
Variables in NAV can either be global (with a scope across the breadth of an object) or local (with a scope only within a single function). Variable names should be unique within the sphere of their scope. There must not be any duplication between global and local names. Even though the same local name can be used in more than one function within the same object, doing so is not a good idea and will almost certainly confuse the next developer that follows. Therefore, we should make our working variable names unique within the object.
Uniqueness includes not duplicating reserved words or system variables. Refer to the C/AL Reserved Words list in the Developer and IT Pro Help. Avoid using as a variable name, any word that appears as an UPPER CASE word in either the Developer and IT Pro Help or any of the published NAV technical documentation. For example, we shouldn't use the words Page or Image as variable names.
Variable names in NAV are not case sensitive. There is now a 128-character limit on variable names (but still a 30-character limit on field names in tables). Variable names can contain all ASCII characters except for control characters (which can contain ASCII values from 0 to 31 and 255) and the double quotes (ASCII value 34) as well as some Unicode characters that are used in languages other than English. Characters outside the standard ASCII set (0-127) may display differently on different systems.
Note that the compiler won't tell us that an asterisk (*, ASCII value 42) or question mark (?, ASCII value 63) cannot be used in a variable name. However, since both the asterisk and the question mark can be used as wildcards in many expressions, especially filtering, neither one should be used in a variable name.
The first character of a variable name must be a letter between A and Z (upper or lower case) or an underscore ( _, ASCII value 95) unless the variable name is enclosed in double quotes when it is referenced in code (and such names should be avoided). Alphabets other than the 26-character English alphabet may interpret the ASCII values to characters other than A to Z and may include more than 26 characters. A variable name's first character can be followed by any combination of the legal characters.
If we use any characters other than the A-Z alphabets, numerals, and underscore, we must surround our variable name with double quotes each time we use it in the C/AL code (for example, Cust List, which contains an embedded space, or No., which contains a period).
When we create a variable with a complex data type such as Record, Report, Codeunit, Page, XMLport, Query, or Testpage, and do not supply a name; the variable name will be automatically generated according to C/AL Coding Guidelines by the Development Environment.
See Naming Conventions in the Developer and IT Pro Help for additional guidance to name C/AL variables.