Kbase P31584: Dynamics: Where and How To Validate When Using SDOs
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
7/16/2008 |
|
Status: Verified
GOAL:
Where and how to validate when using SDO's
GOAL:
How to add validation to a SmartDataObject ?
GOAL:
How to check RowObjUpd in server side validation procedure ?
FACT(s) (Environment):
Dynamics 2.0A
Dynamics 2.1A
Dynamics 2.1B
OpenEdge 10.x
All Supported Operating Systems
FIX:
This Solution describes how to validate using the new validation hook procedures that are available in Progress Dynamics and later versions of the ADM2 framework.
The four original validation procedures in the ADM2:
preTransactionValidate
beginTransactionValidate
endTransactionValidate
postTransactionValidate
have been expanded to be fired for each of the record events (create, delete and update).
The following is a list of the twelve new validation procedures:
Create event
CreatePreTransValidate
CreateBeginTransValidate
CreateEndTransValidate
CreatePostTransValidate
Write event
WritePreTransValidate
WriteBeginTransValidate
WriteEndTransValidate
WritePostTransValidate
Delete event
DeletePreTransValidate
DeleteBeginTransValidate
DeleteEndTransValidate
DeletePostTransValidate
The original ADM2 standard procedures can still be used to do the validation to preserve backwards compatibility. However the original ADM2 validation procedures and the new Dynamics validation procedures cannot be used in combination.
To make use of the new validation procedures, use of a Data Logic Procedure associated with the SDO is required. The validation procedures must be added to this Data Logic Procedure.
The Dynamics validation procedures are executed according to the record event, so it is no longer necessary to check the RowObjUpd temp-table to know what event occurred for which record.
This table shows what set of procedures are executed for each record operation:
Operation Set of validation procedures that will be executed
Add Create, Write
Copy Create, Write
Delete Delete
Update Write
Instead of the RowObjUpd, two new buffers were added to reference the update and old buffer. The update buffer has the name b_<tablename> and the old buffer has the name old_<tablename>. Therefore, if a procedure for the customer table is customized, the update buffer will be b_customer and the old values will be in the old_customer buffer.
The following pseudo-code shows in which order the validation procedures are executed and which are in the transaction block scope:
CreatePreTransValidate
WritePreTransValidate
DeletePreTransValidate
DO TRANSACTION ON ERROR UNDO, LEAVE:
CreateBeginTransValidate
WriteBeginTransValidate
DeleteBeginTransValidate
CreateEndTransValidate
WriteEndTransValidate
DeleteEndTransValidate
END.
CreatePostTransValidate
WritePostTransValidate
DeletePostTransValidate