Validations

The purpose of a programming validation model is to enable the development of validations, without forcing the developer to write the same validation code several times. All checks and validations in the code should only be made once, and the code should be public and accessible from all parts of the application (i.e. different components). This means that ordinary interface mechanisms should be used as much as possible.

Validations should always be done in the server, but the client also validates input in the window before data is sent to the server, for example data type and length, and if the attribute is mandatory or not etc. It is preferable to reduce the number of validation errors in the client since the server will only show the first validation error on each save and not the complete list of errors.

There are four different types of validations:

Validation Type	PL/SQL Method
Validation of attributes used inside a class	Check_Common___,  Check_Insert___,  Check_Update___
Validation of  fields for direct client response	Separate methods
Validation of  foreign keys used from other classes	Exist
Validation before removing objects from a class	Check_Delete___

The following sections will describe the different server validation types, how they work and how they are integrated in the Foundation1 development environment.

Attribute Validations

Validation of attributes is done in the methods Check_Insert___ and Check_Update___. These two methods include only specific validation when records are inserted or updated. Validations that are common for both insert and update should be done in Check_Common___ to avoid duplicated code. This method is called from the other two.

The client calls method New__ or Modify__ with option CHECK to make the validation part without inserting or updating any rows in the database. This option solves situations with error messages, without performing any rollback of transactions, when the client tries to save information.

The example below shows how the base validation methods works. Note that these procedures are automatically generated and they contain only validation generated from the model. Any entity specific validation can be added by overriding the methods. It is also possible to change the validation behavior with different code generation properties.

Reference Validations

Another type of validation is to check whether a specific base data value exists within its corresponding logical unit (typical foreign key reference) to ensure database consistency. The standard framework method is named Exist. The method is public and therefore accessible from all other logical units and is implemented as a stored procedure with any foreign key as input parameters. The algorithm is as follows:

• If the attribute exists, then the procedure Exist will return to the calling procedure and this procedure continues
• If the attribute does not exist, the procedure Exist * * will call the system service method Record_Not_Exist in package Error_SYSand this will do the following:
  1. Fetch a proper language independent error message string from the text database.
  2. Raise an Oracle error by calling system procedure raise_application_error and use specific error string.
  3. The error will be raised through the call stack to a valid exception handler in Oracle Server.

Remove Validations

One typical issue in development of business applications is to decide whether it is possible to remove an entity instance and how the entity will know about references from other entities.

For example, should it be possible to remove a customer if it has "unpaid customer invoices" and the customer status is "active". Business rules like this can be implemented by overriding standard method Check_Delete___. Complex code should be placed in a separate procedure for this purpose and called from Check_Delete___.

The procedure Check_Delete___ has three purposes:

• Decide if deletion is possible due to the attributes within this entity (like status "active" in the example above)
• Decide if deletion is possible due to the existence of foreign keys and if follow on actions is needed.
• Decide if deletion is possible due to the entity attributes of foreign keys(like "unpaid invoices" in the example above)

There are three ways to handle the deletion of a record if it is referenced from other records:

• Restricted delete
• Cascade delete
• Custom delete

For descriptions about the different delete behaviors and how to use them, see Associations.