Field Rules/Triggers and the Object Access Module

The field (and table) level validation rules which you have defined in the Repository are implemented in the Object Access Module, (also referred to as the I/O Module). The Repository validation rules cannot be tested until an Object Access Module (OAM) has been created. For example, a data entry screen may include the Employee Number field. This field on the screen has no validation rules associated with it until the field is used to perform a table operation such as adding a new record to the Employee Master table. When the insert to the database is performed, the Employee Number validation checks in the OAM are executed and error message will be sent back to the screen.

When you have added or changed any of the validation rules in the Repository, it is necessary to make the table operational again. The OAM protects the functions from changes to rules so that the functions do not have to be recompiled. When you change a field level rule, you must use impact analysis tools to determine which tables, if any, are affected by the rule change. You must manually request that the appropriate Object Access Modules be rebuilt. LANSA will not detect this change. If changes are made to rules at the table level, these changes are detected by LANSA and will cause the OAM to rebuilt.