Other observations regarding LANSA Database Triggers

• Database Triggers are always called - for example if a table 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 table. Another example is that CLRPFM is not allowed for tables with before delete or after delete database triggers.

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

• Export of IBM i Other tables (and indexes) 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 table 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 table when it has DB Triggers attached and enabled, for example a table with before or after delete triggers cannot be the subject of CLRPFM, and a table 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 table, 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 tables 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.