Kbase 21182: ADM2 -- Where and How To Validate When Using Split SDO
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
16/10/2008 |
|
Status: Verified
GOAL:
How to use the validation procedures 'preTransactionValidate', 'beginTransactionValidate', 'endTransactionValidate' and 'postTransactionValidate'
GOAL:
How to handle validation with SmartDataObjects
GOAL:
How to achieve validation in a SDO on client side and server side
FACT(s) (Environment):
Progress 9.1x
FIX:
General Explanation:
When using split SmartDataObjects, it is important to know which validation procedure will give the best performance in minimizing the database access and network traffic. Split SmartDataObjects have the ability to handle validations on the Client and the Server side. Here is a list of the validation processes and where they run.
Client Side
- <ColumnName>Validate
- RowObjectValidate
Server Side:
- preTransactionValidate
- beginTransactionValidate
- endTransactionValidate
- postTransactionValidate
These procedures are 'User-Defined' procedures, which means that they are not in the ADM2 architecture. They must be added by the user following the naming convention.
All procedures are called with the NO-ERROR condition, therefore if the process is not created, the SDO will not show errors.
If the validation doesn't require database access, the right place to create them is on the Client side using the rowObject temp table. When an error occurs, the string on the RETURN statement will be shown as an alert-box error and the update will be canceled.
Let's go one by one .....
-- Client Side
RowObjectValidate:
In the procedure RowObjectValidate, the whole rowObject temp table can be validated.
This example shows how to use the RowObjectValidate:
PROCEDURE RowObjectValidate:
/*Validate the customer number */
IF RowObject.custnum = 0 THEN
RETURN "Customer number can not be zero".
/*Validate the customer address */
IF RowObject.address = "" THEN
RETURN "You must to add an address".
END PROCEDURE.
<columnName>Validate:
The procedure <columnName>Validate, validates once each field. According to the name convention the procedure must be the field name plus "Validate". This must have an input parameter defined; this parameter is the field value. Here is an example that validates the customer address using <columnName>Validate:
PROCEDURE addressValidate:
DEFINE INPUT PARAMETER pcAddress AS CHARACTER NO-UNDO.
IF pcAddress = "" THEN
RETURN "You must to add an address".
END PROCEDURE.
-- Server Side
On the Server side the validation procedures are executed in the following order:
- preTransactionValidate
- beginTransactionValidate
- endTransactionValidate
- postTransactionValidate
The transaction scope lies in the beginTransactionValidate and endTransactionValidate procedures.
The preTransactionValidate procedure has access to the RowObjUpd temp-table and here the transaction is not yet active. Therefore the update should be aborted here if necessary.
The beginTransactionValidate procedure has access to the RowObjUpd temp-table and the database records. Now the transaction is active in this procedure and this is the place to make comparisons of updated data with database data.
The endTransactionValidate procedure has access to the database records, but not to the RowObjUpd temp-table. In this procedure you can update to related tables or accumulate totals.
The postTransactionValidate procedure has no data access but it sends the status messages.