In addition to defining schema trigger procedures that are always executed when an operation occurs on a table, you can also define trigger blocks within your application that act on these events, much as you can define triggers for user interface events. These triggers are not of great utility, but there may be circumstances where you need the same block of code to execute regardless of which of a number of different update or find statements against a table are executed in a portion of your application.

A session trigger is in scope while the procedure that defines it is running. The code in the trigger executes in the context of the procedure that defines it, regardless of where the event occurs that fires the trigger. Therefore, it can access local variables and other procedure objects not available to the procedure where the event occurs.

The syntax for session triggers is modeled on the syntax for user interface events:
ON event OF object [ reference-clause ] [ OVERRIDE ]
   { trigger-block | REVERT }

The event can be CREATE, WRITE, DELETE, FIND, or ASSIGN, as for schema triggers.

The object is a database table name in the case of CREATE, DELETE, FIND, and WRITE triggers, or a database field qualified by its table name for the ASSIGN trigger.

The reference-clause applies only to the WRITE and ASSIGN triggers. For the WRITE trigger it is:
[ NEW [BUFFER] new-buffer-name ] [ OLD [BUFFER] old-buffer-name ]
For the ASSIGN trigger it is:
OLD [VALUE] old-value-name [ COLUMN-LABEL label | FORMAT format |
  INITIAL constant | LABEL string | NO-UNDO ]

If you include the OVERRIDE option, then this trigger block executes in place of any schema trigger for the same event and object. This is allowed only if you checked the Overridable toggle box when you defined the schema trigger in the Data Dictionary. Otherwise, an error results when the trigger block is executed.

The trigger-block is a single statement or DO END block just as for user interface triggers. The trigger block executes as would a call to an internal procedure in the same place in the code.

If the AVM encounters an additional session trigger for an event and object when a trigger is still in scope for that combination, the new one replaces the old one for the duration of the new trigger’s scope. Alternatively, if you use the REVERT option in a session trigger block, the current session trigger for the event and object is canceled and the previously executed session trigger definition is reactivated. If there is no other session trigger on the stack, then the session trigger is deactivated altogether.