Warning: Advanced Material

Alventis and Designer support Field-Level and Record-Level Validation. Basically, you can specify a condition that must evaluate to True for an individual field's value to be accepted during record editing – or the whole record to be considered valid when posting it. The validation conditions are specified using the SQL language. Technically speaking, the condition ends up being used as the expression in a query's WHERE clause, so you can use whatever SQL syntax is legal for this clause.

To edit Validation conditions, you must indicate which table's Validation you want to edit using any of the following means:

Once this is done, click the Validation button to open the Validation dialog. Note that this dialog is modeless to allow you to switch to another form in Designer while leaving it open.

The Validation dialog is remarkably simple. All it has is a list of conditions in a grid.

Create new conditions by inserting new records in the list. Delete them by deleting the corresponding record. Re-order the conditions using drag-reordering.

Item specifies what the condition applies to. This can be an individual field or the entire record.

Rule must be set to the desired validation expression.

Error message is the message you want displayed to the user if the validation of this condition fails.

The field-level expressions are evaluated when the user edits a field's value and tabs-out of the field (this action posts the value to the field). If the validation fails, the user receives the error message you specified for the specific failed condition, and he is prevented from leaving the field until he fixes the problem.

Record-level expressions are evaluated when the user attempts to post the whole record. The principle of operation is same as described above.

If multiple validation rules exist for a single posting operation (be it field-level or record-level), they are all applied in the order in which they are listed in the Validation dialog. The first rule that fails displays its error message and aborts the operation. You may therefore find it useful or convenient (both for you and for the end-user) to specify multiple rules per item instead of a single "combined" rule.

For example, you could have the following two record-level rules for the Contacts table:

LName (last name) must not be empty

DateOfBirth must be between 1950 and 2000

You could then express each rule individually with the following setup:

This "condition separation" will make it quite clear to the user what exactly his problem is. You could of course specify both conditions in a single Rule, but the user would have to guess which problem he hit.

Note that the above example is merely for illustration purposes: in reality, since each of the above rules applies to a single field, it would probably make more sense to make them field-level conditions. And this is pretty much how you should approach validation: