The VALIDATE statement is supposed to "Verifies that a record complies with mandatory field and unique index definitions." But it seems that VALIDATE does also execute the record's write trigger. Question a) Why is that happening? It's not needed to perform the documented purpose of the method Question b) Is that documented somewhere? Question c) Is it a bug or a feature? Happy Turkey-Slaugthering everybody!
The VALIDATE statement is supposed to
"Verifies that a record complies with mandatory field and unique index definitions."
But it seems that VALIDATE does also execute the record's write trigger.
Question a) Why is that happening? It's not needed to perform the documented purpose of the method
Question b) Is that documented somewhere?
Question c) Is it a bug or a feature?
Happy Turkey-Slaugthering everybody!
Not sure if it's by design or a bug, but we (admittedly ill-advisedly) make use of the "feature". In a larger transaction we use it to force the write triggers to fire before the transaction scope would naturally cause them to fire so that certain actions have been undertaken by the write trigger before we continue with processing other stuff. Like I say, it's horrible but not something I have great desire to rewrite! :)
OK - It's actually documented. Missed it a couple of times when reading :-)
"If a field or table has been modified, the VALIDATE statement causes WRITE events and all related WRITE triggers to execute."
Still - why is that happening?
VALIDATION should be done before the WRITE. Triggers happen after WRITE. Triggers CAN be used for validation. But it should still be considered bad practice to use triggers for validation.
Well, not much of a fan of using triggers but normally validation done in triggers is not considered a bad practice... the fact triggers ran in client space instead of the server itself makes triggers al together a bad choice :(
As for VALIDATE, I've always used that in lieu of RELEASE just to get those darn triggers to fire.
As I figure, you can't do the index uniqueness test w/out doing a write, so a buffer with a pending write needs to have the data committed to do that test, and that in turn'll fire the write trigger.
I did a session-trigger based replication system in the 9.* days and used VALIDATE() to force a WRITE trigger to ensure the replication code captured the data correctly.
see also database trigger documentation
from OpenEdge® Web Paper: ABL Database Triggers and Indexes
When the AVM changes the contents of a record and validates it for a particular database table,
the AVM first fires all applicable WRITE triggers, then fires all applicable REPLICATION-WRITE
triggers. The AVM automatically validates a record when releasing it.You can also use the
VALIDATE statement to explicitly validate a record. In either case, WRITE triggers execute before
the validation occurs (so WRITE triggers can correct values and do more sophisticated validation).
the AVM might execute the WRITE triggers for a single record more than once before it writes the
record to the database, if it validates the record more than once and you modify the record between
validations. (A modification is considered any change, even if you return the original value.).