ADM2- Rowobject Validate: Old Buffer Value

You should be able to get the RowObjUpd record that has the old data using the RowNum field of the RowObject record.

for each RowObject:
    find RowObjUpd where RowObjUpd.RowMod = "" and RowObjUpd.RowNum = RowObject.RowNum no-error.
    if avail RowObjUpd then 
    do:
       /* do stuff here */
    end.  
end.

I'll try to give some general information about SDO validation.

The RowObjectValidate is a validation hook that is supported on the server (as decided by the SubmitServerValidation property), but always fires on the client side. In addition to this general hook there is also a Validate hook for each changed field that follows the same rules and are controlled by the same property. These hooks should never have any refefence to the underlying physical database data. In OERA these hooks would be replaced by logic in the Business Entity.

The SDO also supports server side and transaction hooks, which can have (and often has) references to the physical data and thus are the equivalent of the data access layer in OERA:

preTransactionValidate

beginTransactionValidate

endTransactionValidate

postTransactionValidate 

These hooks only have access to the RowObjUpd table and fire once for each submit of changes, which means that you have to implement the actual validation inside a for each RowObjUpd to ensure that the submitted records are validated. You will also need to use the RowMod field to identify what kind of change the record is representing. "A" = Add, "C" = Copy, U = "Update (write), "D" = delete and blank is the before image record for the update. You should never implement different logic for Copy and Add though even if we allow it. A new record  is a new record irrespective of how it was added.  

The pre- and post-  hooks fire outside the transaction while the begin- and end- fire inside the transaction. All these hooks are (very) loosely coupled and an error is indicated by a return of any  non-blank value (which also is the error message that will be shown). A string (error) returned from the transaction hooks will undo the transaction while an error from the other hooks will cause a RETURN. (There is really no point in returning a string (error) from the post- hook)

Alternatively the SDO supports row level action based hooks which fire for each submitted record and action in the same 4 places as the general ones. You can only use a general hook or row level action hook at each level. The benefit of the row level hooks are basically that you have access to the RowObjUpd record and don't need to do a find or for each. The drawback is that there are a lot of hooks to cover all actions. These row level hooks were originally added for Dynamics only, and the Data Logic Procedure defines dedicated buffers for both the old and the new value to use for the write event. I do not remember how well these row level hooks work for a regular SDO without a DLP, but it should be very easy to test.

The row level action hooks follows the following naming convention:  TransValidate ( = create, delete or write, = pre,begin, end  or post).

I suggest you read more about the validation support in the Developing Your Application’s Business Logic chapter in the ADM and SmartObjects Documentation.

http://communities.progress.com/pcom/docs/DOC-47938

Message was edited by: Havard Danielsen