This makes the LANSA Repository rules available to all I/O done against a table, whether made via LANSA or via non-LANSA means. For example, when a table is updated with an RPG or COBOL application, the validation rules within the Repository will be enforced, and any LANSA Trigger functions will be executed. In addition, whenever a database trigger is triggered for a table, a trigger environment user exit program, DCTRGENVUE, must be in the job's library list so that the correct LANSA environment can be established. Database Triggers can only be enabled for a table in an RDMLX partition.
What happens when I enable Database Triggers for a table?
When a table is enabled for Database Triggers, a Database Trigger program name is needed. This is initially defaulted to DB <filename>, (as described in Database Table Trigger in the Technical Reference Guide) but can be overridden if this causes duplicate names with another OAM or Database Trigger program name. When the table is next made operational, a Database Trigger program is generated and compiled to run in a named activation group, any Database Trigger processing is added to the OAM, and any triggers added to the database, according to the validation rules and triggers defined for the table.
|
Note: * means not implemented in the database
The Database Trigger program and database triggers are created in the I/O module library. The triggers are named:
LANSA_<program library>_<partition>_<library>_<file>_<trigger time>_<trigger event>
where:
<program library>is the LANSA program library, for example DCXPGMLIB
<partition> is the LANSA partition, for example PRD
<library> is the table library, for example DCXPRDLIB
<table> is the table name, for example PSLMST
<trigger time> is the trigger time, for example BEFORE
<trigger event> is the trigger event, for example INSERT
An example of an entire trigger name could be LANSA_DCXPGMLIB_PRD_DCXPRDLIB_PSLMST_BEFORE_INSERT.