Triggers Dos and Don'ts
-
It is strongly recommended that you do not associate triggers with system files.
-
When you write DataBasic programs or subroutines, always include the ON ERROR clause for statements that update files. This is especially important when using triggers, since any failure caused by a trigger aborts the DataBasic program unless the ON ERROR clause is present.
Note
If the cataloged DataBasic trigger subroutine cannot be found, the trigger returns an error and the update is aborted. This is because the file is no longer be protected by its business rules and invalid data could be inserted.
-
If a trigger updates other files, it might cause other triggers to run. Reality limits the number of levels you can nest triggers to 256. Be careful to use conditional statements to avoid infinite loops that can be caused by nested triggers.
For example, if you have two files that contain related data, you might use triggers to ensure that whenever one file is updated, so is the other. However, you must ensure that when one file is updated and its trigger runs to update the other file, the second file's trigger does not then attempt to update the first file.
-
PRE-DELETE and POST-DELETE triggers run even if the item specified does not exist. You should test element 16 of the ACCESS function for this situation and take appropriate action.
-
Avoid writing to the screen from within triggers. This could corrupt an existing application display.
See also
How to Write an Embedded Basic Subroutine