Record Definition Planning

Before you begin to create record definitions, you should know how you plan to use the record definition, the fields that it will contain, special edits that you would like to see performed on the record definition, or specific fields in the definition.

You define two layers of information:

• Record level

• Field level

At the record level, determine the ultimate purpose of the record definition and how it will be used in the system. Is it destined to define an underlying SQL table to hold data? Are you building a view to join or retrieve information from other tables? Do you need a temporary work record where you can store derived data?

You can audit record-level changes, as opposed to individual fields contained in the record definition, which is an efficient alternative if you plan to audit several fields. You can also establish a more sophisticated use of record definitions, such as sharing information in tablesets and multi-language controls, at the record level.

At the field level, plan the details of what types of fields to add. Should they be character fields or number fields? Should automatic formatting be used? What are the keys to the data stored in the database? Which fields should you audit? Do you want to specify prompt tables so that users can select from lists of valid values that are stored elsewhere in the database?

In most cases, if you are creating a record definition for a SQL table, you don’t have to worry about record-level definitions for parameters and conditions. Unless you change how a record definition is used, the system automatically assumes that you are defining a record definition for an underlying SQL table.