ADM2 - SDO: How to change a changed field?

[moveIT]

In procedure beginTransactionValidate I have to run some code if a field (LOGICAL) was set to true. If the BL returns that it is not allowed to set this field to true, an error sould occur and saving the record should be stopped (no problem with RETURN "<error-text>":U). But also the value of this field should be set to false and displayed in a smartdataview which does´t work. The field is displayed with true. How can this be done?

code example:
FOR EACH RowObjUpd WHERE RowObjUpd.RowMod = "U":U NO-LOCK:
IF LOOKUP (<field>, RowObjUpd.ChangedFields) <> 0 AND
RowObjUpd.<field> = YES
THEN DO:
RUN <BL> (OUTPUT llValid).
IF NOT llValid THEN DO:
RowObjUpd.<field> = NO. /* doesn´t work! */
RETURN "<error-text>":U.
END.
END.
END.

Regards,
moveIT

 

[joey.jeremiah]

a couple of things -

returning an error in the beginTransactionValidate backs out of the transactions. only if the transaction successfully commits the rows are refreshed to reflect any other changes, like, sequences etc.

the RowObject is the data object's result set. the RowObjUpd is a copy of the RowObject that holds all the changes made to the query. in a distrbuted mode the RowObjUpd is only an input parameter sent back to the server. you're looking to change the viewer object widgets screen-value.

adm has procedures and event procedures for almost every event, action, process etc. you can create a new override procedure with the same name and add behavior before and after the original procedure executes, for example, you could add behavior to the updateRecord event procedure in the viewer object.

have a look at the data object query and update operations and validation procedures chapters in the adm and smartobjects doc. and the adm reference doc for a complete list of procedures and short descriptions.

 

[lord_icon]

Begin the validation EARLIER than that.
Don't wait until the end. Prevention is better than cure.
Good UI design would NOT allow the wrong data to be accepted reducing the validation required at the assign/end process. Use something like the ON LEAVE trigger for the widget. So when the user moves to the next required widget values, FLAG fall down.
You know then at assign time validation has already occured, on-the-fly, data is correct less work for the compiler at run time.

 

[joey.jeremiah]

icon, there's no need to take it personally.

Begin the validation EARLIER than that.
Don't wait until the end. Prevention is better than cure.
Good UI design would NOT allow the wrong data to be accepted reducing the validation required at the assign/end process. Use something like the ON LEAVE trigger for the widget. So when the user moves to the next required widget values, FLAG fall down.
You know then at assign time validation has already occured, on-the-fly, data is correct less work for the compiler at run time.

... less work for the compiler at run time ? that's interesting.

although your advice mostly make sense in most cases most of the time, and apparently in life

frameworks have their own way of doing things, that fits into their order execution, error handling, avail or free triggers, organization etc.


in adm and dynamics there are record-level (and field-level) validation procedures defined in the data object that are executed on client-side.

and transaction-level procedures executed on the server-side that have access to the business logic as, i think, this case requires.

validation procedures chapter in the adm and smartobjects doc.

 

[lord_icon]

This is NOT ADM specific. This is applicable with both ADM(1) AND ADM 2. It is basic GUI design. Think objectively, data is correct when initialized and you wish to trap for the assign process. The block you require is the VALUE-CHANGED trigger to the widget. Prevention is better than cure. STOP the user early from entering pants data, do not wait until assign time, the mistake has already been made.

 

[joey.jeremiah]

I think I am being objective. It's not personal if that's what you're saying.


Again, ADM has it's own explicit, documented validation method.

In the same way that you should use the ADM error/exception handling with a return statement and not ignore it with your own.


And obviously not all validations can be done in the user interface separate from the data.

Some validations require access to the data, and some validation are even done inside the transaction.

For example, checking if the data was changed by someone else after it was fetched (this method is called optimistic locking).