Release 10.1A: OpenEdge Development:
ADM and SmartObjects

> ## Record-level validation procedures

> You can define a validation procedure called `RowObjectValidate` in the SmartDataObject for the temp-table record as a whole. This record-level validation procedure (also called a row validation procedure) can perform cross-field validation and other kinds of checks for a set of updates to a single record. The `submitRow` function in the super procedure `data.p` executes the record-level validation procedure (if defined) whenever one or more field values in a record are updated, after the field validation procedures run. The procedure can access any field in the RowObject row by name and, like the field-level validation procedure, it signals error by `RETURN`ing an error message text to the caller.

> Note: Because the `RowObjectValidate` procedure can access any field in the row object by name, you can use record-level validation instead of field-level validation to work around the restriction that field-level validation executes only when a field value changes.

> The fact that `RowObjectValidate` procedures in a SmartDataObject run whenever one or more field values in a record are updated has a side effect you must be aware of. If your `RowObjectValidate` procedure validates a field that is not included in a visualization that updates the table and the procedure returns an error, the application user cannot access the field or fix the error.

> Caution: `RowObjectValidate` procedures run for every visualization that can add or update the table. If you add a `RowObjectValidate` procedure to a SmartDataObject, make sure any visualization that might fire the procedure includes the appropriate fields so application users can add or correct data as necessary to pass the validation check.

> Suppose, for example, a customer SmartDataObject includes a `RowObjectValidate` procedure that ensures at least one of the following fields—phone, fax, email address—is populated for a customer record. If the application that uses this SmartDataObject includes a SmartDataViewer that can add customer records but does not include any of these fields, the validation procedure will not allow the application user to add a record and will return an error noting the user must enter either a phone, fax, or e-mail address. However, the user cannot access these fields and will not be able to enter any of these values.

> The following example, which uses the Progress sample database, describes a SmartObject application that implements a record-level validation procedure in a SmartDataObject. Specifically, it creates record-level validation that ensures that application users enter credit limits greater than zero.

> | To implement a record-level validation procedure in a SmartDataObject:

> 1. Create a SmartWindow.

> 2. Create a SmartDataObject for the customer’s table that includes the name and credit-limit fields.

> 3. Create a SmartDataViewer for the SmartDataObject in Step 2, with its fields in it.

> 4. Drop the SmartDataObject and SmartDataViewer onto the SmartWindow and link them with Data and Update links.

> 5. Drop a Commit SmartPanel on the SmartWindow and link it to the SmartDataObject with a Commit link.

> 6. Drop a Save SmartPanel onto the SmartWindow and link it to the SmartDataViewer with a TableIO link.

> 7. Create in the SmartDataObject an internal procedure called `RowObjectValidate` that has the following code:

>     If rowobject.credit-limit <= 0 THEN RETURN
>     "Credit limit must be greater than zero".

>     END PROCEDURE.

> With this record-level validation procedure in place, an application user who enters zero for the credit limit receives the specified error message.

> As another example, the following code, when placed in the `RowObjectValidate` internal procedure, cancels any data change (add or update) where the value of SalesRep is `SLS` (this is a new sales rep) and the Balance or CreditLimit fields are out of a specified range:

>     IF RowObject.SalesRep = "SLS": THEN
>       IF RowObject.Balance > 0 OR RowObject.CreditLimit > 5000 THEN
>         RETURN "SalesRep Not Authorized For This Change".

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