Progress
ADM 2 Guide


Transaction-level Validation Procedures

As updates are made, the ADM creates a version of the RowObject temp–table, called RowObjUpd, that contains only the rows that are being updated (that is, modified, added, or deleted). It passes the RowObjUpd temp–table to the server side of the Commit process, which finds the corresponding database records (using the RowIdent field) and moves the update rows into those records. ADM allows you to implement transaction-level validation at various points in the process.

The SmartDataObject contains four entry points for transaction-level validation procedures: preTransactionValidate, beginTransactionValidate, endTransactionValidate, and postTransactionValidate. These entry points are simply procedure names that execute NO–ERROR. If you want your SmartDataObject to perform custom validation at a particular point in a transaction, you simply write an internal procedure of the corresponding name in the SmartDataObject. These procedures are executed where the database connection is. If the SmartDataObject is divided between client and AppServer, they are executed on the AppServer.

The four entry points operate as follows:

Each of these procedures has access to the RowObjUpd table and to any connected database tables. The procedures signal error by RETURNing an error message; if any of these procedures does return an error message, processing stops. Thus:

NOTE: The version of ADM 2 available in Progress V9.0 provided a single entry point called TransactionValidate for transaction-level validation. The preTransactionValidate procedure effectively replaces TransactionValidate, but TransactionValidate is still supported for compatibility with the previous release. As is the case with preTransactionValidate, TransactionValidate executes NO–ERROR so that it runs only if it has been defined for the SmartDataObject.


Copyright © 2004 Progress Software Corporation
www.progress.com
Voice: (781) 280-4000
Fax: (781) 280-4095