20. Writing 4GL Statements : Forms-Control Statements : Validating Data Fields
 
Share this page                  
Validating Data Fields
Data in fields is validated according to criteria established in VIFRED when you create the form using the ABF FormEdit operation. Most validations are triggered by cursor movement out of fields. The three phases of the validation process check that:
• A required (mandatory) field has an entry
• The field has the correct data type
• Any "custom" validation check specified in the VIFRED form definition is performed
The statements for explicit validation of existing data are:
validate
validrow 
validate field
The validate statement checks every field in the current form for which validation checks were specified in VIFRED through the ABF FormEdit operation.
The validate field statement performs validation checks on simple fields or table fields as you have defined them in VIFRED. Validating rows in table fields is covered in Manipulating Table Fields and Arrays.
If a field fails a check, FRS displays an error message and places the cursor in the field that failed so that the user can enter correct data. For example, if you have specified a validation check of ">=20000" for the salary field, the following statement checks the value entered by the user:
validate field salary;
If the amount entered is less than 20,000, the field fails the validation check.
While you cannot perform a validation on a derived field directly, any source fields must be valid in order for the value of the source field to be defined.
Validation and Mode
The display mode of the form affects whether validation checks are made on the simple fields or table fields. The following table summarizes these effects. In the table:
Y indicates that a validation check takes place
N indicates that a check does not take place
D indicates a data type check only
Footnotes to entries in the Action or Statement column follow these tables.
Simple Fields
Forms Display Mode
Action or Statement
Fill
Read
Update
Query
Field validated on leaving field? (1)
Y
N
Y
N
Form field validated when program references it?
Y
Y
Y
D
Form field validated when program assigns a value?
D
D
D
D
Field validated when validate field statement executes?
Y
Y
Y
D
Fields validated when return statement executes? (2)
N
N
N
N
Table Fields
Table Field Display Mode
Action or Statement
Fill
Read
Update
Query
Field validated on leaving column or table field? (1)
Y
N
Y
D
Field validated on tabbing backward to previous column or out of table field? (1)
N
N
N
N
Current row validated on moving to row above or below? (3)
Y
N
Y
D
Column validated when program references a value in the table-field column?
Y
Y
Y
D
Column validated when program assigns a value to the table-field column?
D
D
D
D
Row validated on validrow statement?
Y
Y
Y
D
Visible rows validated before rows in table field scroll out of view, due to user action or program scroll statement?
Y
N
Y
D
Loaded rows validated before loadtable statement executes?
N
N
N
N
Visible rows validated before unloadtable or deleterow statement executes? (4)
Y
N
Y
D
Rows not visible validated before unloadtable statement executes?
N
N
N
N
Validate row to be deleted before deleterow statement executes?
N
N
N
N
Visible rows validated before successful deleterow or insertrow statement?
Y
N
Y
D
Key Validations
Form Display Mode
Action or Statement
Fill
Read
Update
Query
Validation on pressing Menu key or mapped FRS key with validation checking on (through validate=1 on menu line or set_forms/set_frs)?
Y
Y
Y
D
Validation on pressing Menu key or mapped FRS key with validation checking not on? (1)
N
N
N
N
Footnotes to previous tables:
1. Default validations. You can turn this validation off or on with a set_forms frs validate statement.
2. Except displayed fields whose values are supplied by a byref statement. These are validated before the called frame returns.
3. Cannot override these with the set_forms frs validate statement.
4. If a validation check fails, the unloadtable loop ends and no rows are returned.