Technically, we use the term validation rule, which is a rule which is applied when a table is updated or a record is added or deleted. A validation rule is defined for a field, or for a column in a table. A rule defined for a field is implemented when the field defines a table's column.
A rule can be very simple, such as May not be blank or May not be zero. Other more complex rules include:
o Comparison with a list of values
o Comparison with a range of values
o A date check
o A simple logic check
o A complex check which calls a program
o A table lookup rule.
Importantly, the table lookup rule can be used to define referential integrity checks to ensure consistent and complete data is maintained for related tables. For example, a lookup rule for Add to the Employee table, could ensure that Employee Department Code exists in the Departments table.
A rule for Delete from the Departments table, could ensure that deletion is prevented if related Employee records exist for this Department Code.
All validation rules are implemented automatically by a special module which is generated for each table. This is the Object Access Module, usually referred to as an OAM. Visual LANSA applications perform database I/O by calling the table's OAM. When an update fails a Validation Rule, the OAM returns an error status and error message.
Obviously business rules have a number of important benefits, such as the validation logic does not have to be implemented in every component which maintains a table and secondly they guarantee that the validation rules will always be applied.
In addition to validation rules, fields and tables can have triggers. A trigger is a condition that allows a function to be linked to a specific database operation and condition. The trigger function is invoked automatically when a specific type of I/O operation occurs to a file and when a specific set of conditions are met.
See Field Rule and Trigger Development.
See Table Rule and Trigger Development.
See What is an OAM?.