Now, I have another DDL trigger and a packaged procedure that captures the DDL to recreate objects that are recursively dropped (such as DML triggers on tables). The DDL is stored in a database table. This trigger can remain permanently enabled, and the table it maintains can be used to see what objects are missing, as well as holding the SQL to rebuild them.
An common example of where this is can be valuable is where a system uses database triggers to capture audit data. This method is often preferred because it generally performs better than having the application server generate additional DML to the audit table, and also captures updates made in other processes. PeopleSoft even deliver processes to generate the DML triggers that write to the audit tables. However, if you alter the table in Application Designer, perhaps only because you are applying a PeopleSoft fix, and apply the changes to the database by recreating the table, then the trigger will be lost. It is then up to the customer to make sure the audit trigger is replaced. There is absolutely nothing to warn you that the trigger is lost, and the application will still function without the trigger, but your updates will not be audited.
When a table is dropped, the trigger calls a procedure in the package that checks for:
- indexes that are not managed by PeopleTools (such as function-based indexes),
- triggers not managed by PeopleTools (other than the PSU triggers created for mobile agents),
- materialised view logs.
- If the table is partitioned or global temporary the DDL for the object being dropped is also captured.
When an object for which the DDL has been captured is explicitly dropped, this is indicated on the table GFC_REL_OBJ by storing the time at which it was dropped. When it is recreated this time-stamp is cleared. Thus it is possible to decide whether something was deliberately or accidentally dropped.