Note that this is a logical flow, not a physical re-enactment of how Teradata Database processes a trigger.
- The triggering event occurs on the subject table.
- A determination is made as to whether triggers defined on the subject table are to become active upon a triggering event.
- Qualified triggers are examined to determine the trigger action time, whether they are defined to fire before or after the triggering event.
- When multiple triggers qualify, then they fire normally in the ANSI-specified order of creation timestamp.
To override the creation timestamp and specify a different execution order of triggers, you can use the ORDER clause, a Teradata extension.
Even if triggers are created without the ORDER clause, you can redefine the order of execution by changing the trigger creation timestamp using the ALTER TRIGGER statement.
- The triggered SQL statements (triggered action) execute.
If the trigger definition uses a REFERENCING clause to specify that old, new, or both old and new data for the triggered action is to be collected under a correlation name (an alias), then that information is stored in transition tables or transition rows:
- OLD [ROW] values under old_transition_variable_name, NEW [ROW] values under new_transition_variable_name, or both.
- OLD TABLE set of rows under old_transition_table_name, NEW TABLE set of rows under new_transition_table_name, or both.
- OLD_NEW_TABLE set of rows under old_new_table_name, with old values as old_transition_variable_name and new values as new_transition_variable_name.
- The trigger passes control to the next trigger, if defined, in a cascaded sequence. The sequence can include recursive triggers.
Otherwise, control passes to the next statement in the application.
- If any of the actions involved in the triggering event or the triggered actions abort, then all of the actions are aborted.