Dynamics NAV Development for Non-Developers: Part 5 – Adding a Simple Field to a Table
There is sometimes a need to store an additional piece of information about a thing (record) in Dynamics NAV, that does not have a home in the out-of-the-box structure. Often, this additional information is “informational” only and doesn’t need to influence system behavior, such as “look up” to another list, or driving new business rules. In these cases, adding a simple field might be all that is needed.
For purposes of this example, we will add a new field to the item table called “Website Description.” The goal of this field is to allow users to record the description of each item as it appears on the company website – for informational purposes only in NAV.
Adding a field to a table in NAV is relatively straightforward, but requires some care to prevent conflicts or loss of data. Additional information may also be found in the related MSDN Development series, How to: Add Fields to a Table .
To begin, new fields in “stock” tables need to be created in the 50000 to 99999 number range. New fields in custom tables can be created in any number range. Similarly, you can identify whether a table is “stock” or custom by its number: the range 50000 to 99999 typically reflects custom objects. Both the field number and field name must also be unique within the table. For our example here, we will add a new field to the “stock” item table.
Adding a New Field
A brief five-step process is identified below through screenshots. Some nuances related to these steps follows.
- Find and “Design” the table in the Development Environment (Object Designer), see previous NAV Development blog "Part 3: Knowing What I Want to Change" for more information related to identifying and locating the table.
2. Insert a new field (F3) and assign a Field No., Name, Date Type, and Length (if applicable)
3. Select the Properties button (Shift + F4) to address any additional attributes
4. Exit the object until prompted to Save Changes
5. Update the Version List and document your changes consistent with your partner’s approach/methodology
Some additional (random) notes on field changes…
- On tables, more than any other object, it is important to get your definition right the first time. Changing lengths, data types and some other field properties, after data has been entered into that field, can have destructive consequences.
- The saving and compiling of a table should only occur in a database that users are not currently working within. As you should always be developing in a development environment/database, this shouldn’t be an issue. That said, once you are ready to move your updated object to Production, you will want to take the same precaution.
- The properties of the field are often not needed, but there may be instances where you want to control foreign language captioning, table relationships or other attributes not inherently assumed when the field is created.
- When working with field types, you will almost always want to use Code, Text, Decimal, Date or Boolean (checkbox). The distinction between Code and Text is the case sensitivity of the field. As an example, “No.” fields in NAV are type Code while descriptions are type Text. Regardless of what you enter in a “No.” field, NAV will force it to all upper-case. Entered lower-case letters in a text field will be maintained as entered.
The next entry in this series will describe the process to add a field (column) to a list page. In it, we will expose our new “Website Description” field to the Item Card, so users are able to see and edit it.