Constraint Evaluation, Record Validation and Record Storage

The aim of record validation is to check as soon as possible whether a row event (INSERT, UPDATE, or DELETE) is acceptable, and to correct it where necessary or warn the user if there is a problem.

If the row event is acceptable, the record is stored. As a result, its new column values are available to later operations, but the user can still decide to rollback the transaction including the current record storage.

Single-record constraints, as well as non-deferred corrective multi-record constraints, are evaluated as a result of the record storage routine being executed.

In addition, as part of the record storage routine, restrictive multi-record constraints are listed as needing to be evaluated at commit time. Record validation and storage occurs when the user leaves a record after entering a new record (INSERT), changing one or more column values within an existing record (UPDATE), or deleting a record (DELETE).

It also occurs when the user performs another action that implies that the record is ready for validation, e.g., when the window in which the record was manipulated is closed, or when the user issues a commit command by choosing File, Save from the menu bar. On DELETE, the user necessarily moves out of the record because it disappears from the screen. Therefore DELETE is always followed immediately by a record validation. You can explicitly cause the current record to be validated by calling the RecordStore() method.

Record storage begins with the validation of all fields within the record. Next, single-record constraints are evaluated. These may cause field values to be updated and field validation to be repeated.

At the end of record validation, corrective multi-record constraints are evaluated. These may lead to further manipulation on the same or other database tables. Each of these triggered row events calls for its own record storage routine.

•Actions specified for the Post-change, Pre-insert Validation, Pre-update Validation, and Pre-Delete Info Box behavior properties are executed just before record storage.

•Actions specified for the Post-insert, Post-update and Post-delete Info Box behavior properties are executed just after the record storage routine.