Other observations regarding LANSA Database Triggers

Database Triggers are always called - for example if a file that is enabled for Database Triggers has an after read trigger function defined for it, that after read trigger function is called even when using the IBM i command DSPPFM for that file. Another example is that CLRPFM is not allowed for files with before delete or after delete database triggers.

Execution of LANSA database triggers is only available in RDMLX partitions. LANSA files with LANSA Database Triggers enabled cannot be imported into an RDML partition.

Export of IBM i Other files (the physical and any logicals) as non-LANSA objects will require that the database triggers be removed manually before the export is run, and re-added after the export is completed.

Care should be taken before enabling LANSA Database Triggers for a file that is used in existing 3GL applications, as the existing 3GL applications may be coded in such a way that if a Database Trigger failure is signaled back to them, they may simply abort and leave the database in a half updated condition.

After read Database Triggers will be executed as a result of a keyed RPG SETLL, SETGT, C API _Rlocate and the COBOL equivalent operations. This is a design decision in the DB2 for IBM i database.

There are some restrictions to what can be done to a file when it has DB triggers attached and enabled, for example a file with before or after delete triggers cannot be the subject of CLRPFM, and a file with before or after insert triggers cannot be the subject of INZPFM. For more information on such restrictions, refer to the section on "Triggers and their relationship to other IBM i functions" in the DB2 for IBM i Database Programming manual or the equivalent section in the IBM InfoCenter.

After turning on LANSA Database Triggers for a LANSA file, performance from LANSA will be affected. This is unavoidable as the database itself has no way of detecting that the Database Trigger should not be executed in this situation. The Database Trigger program will be executed, determine that it has been executed as a result of an I/O from LANSA, and return.

Because LANSA Database Trigger programs execute in a named activation group, care must be taken if commitment control is used. It is strongly recommended that the section on Commitment Control in the IBM InfoCenter be read and understood before LANSA Database Triggers are enabled. In particular, if the execution of the LANSA Database Trigger program or anything it calls results in database inserts, updates or deletes to files under commitment control, and activation group level commitment definitions are used then the effect on the existing application must be tested in a variety of situations to ensure that the application's integrity is preserved.