Database triggers associate a table or field with a database event. When the event occurs, the trigger executes. ABL does not provide events for all database actions. For example, although you can dump database definitions from a database, you cannot write a trigger for a DUMP event because ABL does not provide a DUMP event.
However, ABL does provide replication-related triggers in addition to standard triggers for certain events. Replication-related triggers help you implement database replication. For more information on replication-related triggers, see OpenEdge Development: ABL Essentials.
The database events that ABL supports follow.
CREATE
When the ABL Virtual Machine (AVM) executes a CREATE or INSERT statement for a particular database table, the AVM creates the record, then fires all applicable CREATE triggers, then fires all applicable REPLICATION-CREATE triggers.
DELETE
When the AVM executes a DELETE statement for a particular database table, the AVM fires all applicable DELETE triggers, then fires all applicable REPLICATION-DELETE triggers, then validates the delete, then performs the delete.
FIND
When the AVM reads a record in a particular database table using a FIND or GET statement or a FOR EACH loop, the AVM fires all applicable FIND triggers. FIND triggers fire only for records that completely satisfy the full search condition, such as a WHERE clause specifies. FIND triggers do not fire in response to the CAN-FIND function.
Note that if a FIND trigger fails, the AVM behaves as though the record had not met the search criteria. If the FIND is within a FOR EACH block, the AVM simply proceeds to the next record. If your application uses the BREAK option of the PRESELECT phrase (which forces the AVM to retrieve two records at a time, so it can find the break), the AVM executes the FIND trigger twice during the first FIND, which is actually two FINDs in succession. Thereafter, the AVM looks one record ahead of the record currently in the record buffer, and executes the FIND trigger before it places the next record in the buffer.
WRITE
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.).
ASSIGN
When the AVM updates a particular field in a database record, the AVM fires all applicable ASSIGN triggers. Unlike the other database events, this one monitors a specific field rather than a table. ASSIGN triggers execute when the contents of the associated field are modified. The trigger procedure executes at the end of a statement that assigns a new value to the field and after any necessary re-indexing. If the statement contains several field assignments (for example, UPDATE name city st), the AVM fires each applicable ASSIGN trigger at the end of the statement. If any trigger fails, the AVM undoes the statement (unless the code specifies NO-UNDO). For more information on replication-related triggers and database replication, see OpenEdge Data Management: Database Administration.
