Microsoft Dynamics Ax (formerly known as Axapta) supports strings, integers, 64 bit integers, enumerated lists, memo fields and images when designing tables.    Some decisions are obvious, for example if you are storing a number then the field type will be numeric while if you are storing a name the field type will be string.  The decision becomes cloudy when deciding between an enumerated list of fixed values and a field of any type that validates against another table.  The object of this discussion is to provide a framework to help you make this decision.

The table in my example MyTable has an enum which represents the type of product.  In this case, the value is good, better and best.   When the user selects the enum values, the Microsoft Dynamics Ax Kernel will convert the literal value to the corresponding integer value when the record MyProductTable record is stored.    It would appear that enums could be used in most instances when you want to validate data in a table.   For example, why not use enums to validate states.  A state list would be constant over many systems and therefore seem logical to set.   Why not use enums for product types, while this may not be constant over many systems it most likely to remain constant in a single environment with minimal changes.   


ID                         String 20

Name                    String 30

Type                     Enum (Good, Better, Best)


Instead of using an enum for our Good, Better and Best type, we could establish a validated field which validates our field against a separate table where we store our types.  This requires us to establish the relationship of the MyTypeValue.ID to our MyProductTable.Type field.  Once the database is established then we would have to build the forms and searches (unless we rely on the autolookup feature) before the product type could be used.  In addition, we have to find/get the MyTypeValue.Name whenever we wish to display the full name of our type.  On the surface, it appears that adding an enum with fixed selections is simpler, easier and more efficient then establishing a validated field. 


ID                         String 20

Name                    String 30

Type                     String 10

where Type is validated against MyTypeValue.ID



ID                         String 10

Name                    String 30


It is true that the simplicity of the enum does support its convenience, the problem is, it can render an application obsolete when used improperly.   Enum’s values are finite and require programming code to influence the application.    A supporting table can support fields in addition to the validating field.  These fields can be used by the user to direct the application to address their specific requirements. 

Therefore, I recommended using enum’s only when you have to route the user to different application paths which are supported by distinctly different application code.  The only exceptions are very simple enums, such as yes/no or very small lists which the user will use the enum’s as filters.  For all other instances, a validated field should be used.  

Michael J. Conti

Vice President of Development – Clients First Business Solutions, Arlington, TX