Release 10.1A: OpenEdge Development:
Progress 4GL Handbook

> ## Database events

> There are five database events you can associate with a trigger procedure:

> - `CREATE` — Executes when Progress executes a `CREATE` or `INSERT` statement for a database table, after the new database record is created. You can use the procedure to assign initial values to some of the table’s fields, such as a unique key value.

> - `DELETE` — Executes when Progress executes a `DELETE` statement for a database table, before the record is actually deleted. You can use the procedure to check for other related records that would prevent deletion of the current one, to delete those related records if you wish, or to adjust values in other records in other tables to reflect the delete.

> - `WRITE` — Executes when Progress changes the contents of a database record. More specifically, it occurs when a record is released, normally at the end of a transaction block, or when it is validated. This book recommends against using the field validation expressions that the Data Dictionary allows you to define because these have the effect of mixing validation logic with user interface procedures. The `WRITE` trigger happens in conjunction with those validations, if they exist, when the record is released or you execute an explicit `VALIDATE` statement. The `WRITE` trigger can replace those kinds of validations without combining validation with the UI.

> - `ASSIGN` — Monitors a single field rather than an entire database record, so you can use it to write field-level checks. An `ASSIGN` trigger executes at the end of a statement that assigns a new value to the field, after any necessary re-indexing. If a single `ASSIGN` statement (or `UPDATE` statement, but you know not to use that anymore) contains several field assignments, Progress fires all applicable `ASSIGN` triggers at the end of the statement. If any trigger fails, Progress undoes all the assignments in the statement.

> - `FIND` — Executes when Progress reads a record using a `FIND` or `GET` statement or a `FOR EACH` loop. A `FIND` trigger on a record executes only if the record first satisfies the full search condition on the table, as specified in the `WHERE` clause. `FIND` triggers do not fire in response to the `CAN-FIND` function. If a `FIND` trigger fails, Progress behaves as though the record has not met the search criteria. If the `FIND` is within a `FOR EACH` block, Progress simply proceeds to the next iteration of the block. Generally, you should not use `FIND` triggers. They are expensive—consider that you are executing a compiled procedure for every single record read from that table anywhere in your application. Also, they are typically used for security to provide a base level of filtering of records that the user should never see. For various reasons, including the fact that a `CAN-FIND` function does not execute the `FIND` trigger, this security mechanism is not terribly reliable. You are better off building a general-purpose filtering mechanism into your application architecture in a way that is appropriate for your application, rather than relying on the `FIND` trigger to enforce it.

> There are also trigger events to support replication of data, so that any change to a database can be copied to another database. These `REPLICATION-CREATE`, `REPLICATION-DELETE`, and `REPLICATION-WRITE` events are described in OpenEdge Development: Progress 4GL Reference .

Copyright © 2005 Progress Software Corporation www.progress.com Voice: (781) 280-4000 Fax: (781) 280-4095