Creating a Generic Dynamics NAV Lookup Table to Encourage Good Behavior
During initial design on a Dynamics NAV project, it is easy to make a decision between employing an Option field or a Code field validated by a dedicated table. We buy what tables we need and off to the races we go.
As a project matures and the table spread of middle age occurs it is not uncommon to deal with a support request that really calls for a validated field, but there aren’t any tables left in the license at that point and time is of the essence. This is when design crimes are committed with the best of intentions and fields may be made with long option strings or for options that are not as static as we would like to think.
Dynamics NAV Lookup Table Solution:
To avoid this situation, we may add a generic lookup table to our projects. In this way, the first table we ever use is always there to make a good choice at a later point in the project lifecycle. This is not an invitation to make a mess and end up with ridiculous quantities of data in a table. When a validation table needs more than Code and Description fields it probably does need a dedicated table. The other vital requirement is that the use of a generic lookup table is transparent to users.
Dynamics NAV Lookup Table Implementation:
Our generic table contains three fields:
- The Code and Description fields are like those in any lookup table
- The “Field Name” field is used to separate the data belonging to entirely different lookups.
Sample Lookup Data
Here we have two values for two unrelated example Lookups:
Adding a field to a table with generic validation:
The only trick is to put a hard coded filter in place to pick out the correct values from our generic table. In this way, users will only see the relevant values and will also only add new values with the correct Field Name.
Our new field is now ready to be placed on any page.