trigger delete

Removes occurrences marked for deletion, when writing updates to the database.

Declaration: trigger delete
Applies to:


Activation: Activated by the store and erase ProcScript commands for each database occurrence of an outer entity and its down entities that was removed by the user (for example, with ^REM_OCC) or by ProcScript.
Default behavior: None
Behavior upon completion: If $status is less than zero, database I/O is terminated and no further triggers are activated for the current I/O request.


This trigger is activated for the outer entity and its Down entities (inner entities representing the many side in a one-to-many relationship with the parent entity). For more information, see Related Component Entities.

If an entity is painted as an Up entity, the deleteUp trigger is activated instead.

If the outer entity is a non-database entity, and the inner entity is a database entity, deleting an occurrence of the outer entity also marks all the retrieved occurrences of the inner entity for deletion.

The process flow when the delete trigger is activated by the store command is as follows:

  1. The store ProcScript statement is issued.
  2. Uniface performs all outstanding data validation checks, if relevant. This includes all syntax and other declarative definitions, and activating the relevant loseFocus, leaveModified, valueChanged and validate triggers.
  3. Uniface activates the delete trigger for every removed occurrence present in the component, unless the cascade delete constraint is in force, in which case the delete trigger is fired only once for each affected entity.
  4. The delete statement in the delete trigger of each entity causes the DBMS driver to delete each removed occurrence.

Programming the Delete Trigger

In the delete trigger, you check the deletion status of an occurrence using the $occdel function.

If the delete trigger contains only a single delete statement, Uniface performs the delete action without invoking the ProcScript interpreter (unless the Debugger is active). This feature improves performance.

Note:  You cannot access the contents of the fields of an occurrence when you are in the delete trigger. If you need to do this, use the remove trigger instead.

Referential Integrity Checks Before Trigger Activation

Before the delete trigger of a removed occurrence is activated, the referential integrity for all inner component entities is checked. Depending on the delete constraints, this can cause the Read, Write, and delete triggers of the inner entities to be fired:

  • For each inner entity with a Restricted delete constraint, the read trigger is fired.
  • For each inner entity with a Nullify delete constraint, the write trigger is fired.
  • For an inner entity with a Cascading delete constraint, the delete trigger is fired only once for each affected entity, instead of for each occurrence.

    If the $CASCADE_TRIGGER assignment setting is used, the delete trigger is activated for all removed occurrences. This, in turn may activate Read, write, or delete triggers of entities that are inner to this entity. For more information, see $CASCADE_TRIGGER.

If you have included an entity marker in a form to ensure referential integrity, the situation can arise where the entity does not exist. In this situation, the delete statement in the delete trigger will fail. This stops any further activation of delete triggers. To avoid this, include a return0 statement in the delete trigger.

Related Topics