There are five database events you can associate with a trigger procedure:
  • CREATE — Executes when the AVM 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 the AVM 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 the AVM 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 guide 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, the AVM fires all applicable ASSIGN triggers at the end of the statement. If any trigger fails, the AVM undoes all the assignments in the statement.
  • FIND — Executes when the AVM 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, the AVM behaves as though the record has not met the search criteria. If the FIND is within a FOR EACH block, the AVM 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.
    Note: If you create a record and only assign part of the index, the record is not released. If you do a FIND on the record using the index, the AVM cannot find the record. Make sure you use a RELEASE statement directly after the ASSIGN to release the record.

There are also trigger events to support replication of data, so that any change to a database can be copied to another database: REPLICATION-CREATE, REPLICATION-DELETE, and REPLICATION-WRITE.