Working with triggers

The following limitations apply in the use of SQL and ABL triggers:

ABL possesses a rich set of trigger mechanisms. ABL triggers are procedures that are written by the user, and they fire when record-oriented events such as creating, deleting, writing, or finding a record occur. ABL triggers are associated with their corresponding database records using the Data Dictionary and execute in the context of an AppServer or an ABL client.

SQL also possesses a rich set of trigger mechanisms. SQL triggers are Java procedures written by the SQL database administrator, and they fire when record-oriented or statement-oriented events, such as inserting, deleting, or updating data, occur. SQL triggers are defined for their corresponding database tables using the CREATE TRIGGER command. SQL triggers execute in the SQL server.

The SQL and ABL trigger mechanisms are parallel but separate. The ABL does not execute SQL triggers, and SQL does not execute ABL triggers. This is because the two types of triggers require different execution engines: SQL requires the SQL engine, and the ABL requires the ABL engine.

Usually, an ABL trigger will contain significant database integrity enforcement logic, or perhaps enforcement of business logic rules. If a database can also be updated by SQL users using SQL statements, the database administrator will want to apply the same enforcement rules when SQL updates occur. To do so, the data-specific logic should be replicated from the ABL trigger to a SQL Java trigger. That new trigger can then be added to the database, using the CREATE TRIGGER statement. SQL will then use that trigger to enforce the defined logical rules and actions.

For more information on using ABL triggers, see OpenEdge Getting Started: ABL Essentials. For more information on SQL triggers, StoredProcedures and Triggers