Data Validation Order

Previous Next

As the user enters and changes data, field values and data manipulations are validated using a system of four set routines:

Field validation

Group validation

Record validation

Transaction validation

Groups are primary key fields, foreign key fields or virtual fields. A primary key group consists of only one field if the primary key is single-column. It consists of more than one field if the primary key spans more than one column; the same applies to foreign key groups and groups of virtual fields.

NOTE: Do not confuse group validation with GUI control groups. The two issues are entirely unrelated.

Field validation occurs when the user leaves the field. Group validation occurs when the user leaves the group and record validation, when the user leaves the record. Note that "leaving the field" can be achieved by actual navigation but also implicitly, by issuing the Save/Commit command, for example.

All new data is validated only once: validation only takes place if the value in a field, group etc. was actually changed, or newly entered by the user.

If the user moves out of a field to the next field within the record, only field validation occurs, followed by group validation if the move is across a group boundary.

Likewise, if the user moves out of a field to the next record, field validation occurs, followed by group validation (if applicable) and record validation.

CAUTION:

To avoid complexity, do not tamper with internal validation handling. In particular:

DO NOT manipulate the current field value in the Post-change method call script for that field. For a similar value adjustment, use the Adjust Change field property instead.

In the Post-change method call script for a field you can, however, manipulate OTHER field values within the record.

DO NOT issue the RecordStore() command, or otherwise manipulate the current record in a record validation property (Pre-insert validation; Pre-update validation; Post-change for the info box).

DO NOT issue the RecordStore(), RecordCreate(), or QueryExecute() command on a column's pre-field-entry, post-edit or post-change action lists.

Example:

The user queries a record with a primary key spanning two columns, changes the value of one of the primary key values (UPDATE), and commits.

In this example the following validations and behavior properties are triggered as a result of the commit command, in the order stated:

1.Adjust Change (Field behavior property)
2.Field validation

Column attribute checks such as Minimum Value

Corrective domain constraints

Restrictive domain constraints

3.Post-change (Field behavior property)
4.Post-Edit (Field behavior property)
5.Group validation

Virtual field groups

Primary key groups

Foreign key groups

Group validation checks for data integrity, such as uniqueness of the key. Some integrity rules, such as the Child Must Exist relationship attribute, are handled as restrictive constraints and therefore occur later.
6.Post-Change (Info Box behavior property; insert/update only)
7.Pre-insert Validation, Pre-update Validation, or Pre-delete (Info Box behavior properties)
8.Record validation

Mandatory checks

Corrective single-record constraints

Restrictive single-record constraints

9.Post-Insert, Post-Update, Post-Delete (Info Box behavior properties)
10.Transaction validation

Corrective multi-record constraints

Restrictive multi-record constraints

11.Pre-Commit (Application behavior property)