Data Validation Order
As the user enters and changes data, field values and data manipulations are validated using a system of four set routines:
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.
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.
To avoid complexity, do not tamper with internal validation handling. In particular:
In the Post-change method call script for a field you can, however, manipulate OTHER field values within the record.
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:
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.