In general, a schema trigger procedure or session trigger executes within the larger context of the procedure containing the statement that causes the trigger to fire, just as if the procedure or block of code had been run following the triggering statement. Keep the following considerations in mind about how triggers operate:
  • ABL does not allow database triggers on events for metaschema tables and fields (which have an initial underscore in their names and a negative internal file number in the schema).
  • You cannot delete a record in a buffer passed to a database trigger or change the current record in the buffer with a statement such as FIND NEXT or FIND PREV.
  • An action within one trigger procedure can execute another trigger procedure. For example, if a trigger assigns a value to a field and you have also defined an ASSIGN trigger for that field, the ASSIGN trigger executes. You must take care that this does not result in either unwanted conflicts between the actions of the triggers or a possible loop.
  • By their nature, triggers are executed within transactions (except possibly for a FIND trigger). Whatever action is encoded in the trigger becomes part of the larger transaction.
  • For all blocks in a database trigger, the default ON ERROR handling is ON ERROR UNDO, RETURN ERROR, rather than the usual ABL default of ON ERROR UNDO, RETRY. You learn more about the ON ERROR phrase in the next section.
  • You can store collections of precompiled ABL procedures in a single file called a procedure library. If you collect together your application’s schema triggers into a procedure library, you can use the –trig startup parameter to identify either the name of the procedure library for triggers or the operating system directory where they reside. See Startup Command and Parameter Reference for more information. Note, however, that source code can never be executed from a procedure library.
  • When you dump and load database records, you might want to disable the schema triggers of the database, both to avoid the overhead of the triggers and to deal with the likely possibility that integrity constraints enforced by the triggers might not be satisfied until the database load is complete. See OpenEdge Database Tools for more information on disabling triggers.
  • For information on how SQL access to your database interacts with ABL schema trigger procedures, see SQL Development.

In the following section about transactions, you learn how ABL uses locks to control multi-user access to data, and what the scope of those locks is relative to the transactions they are used in.