Re: Triggers - enabling and disabling

On 04 Oct 2012 09:44, Åke Olsson wrote:

But we would like to turn on and off the activation of triggers more
or less at will. Status *ENABLED and *DISABLED should work nicely.

The problem is that this operation seems to require private
<ed: exclusive allocation> access to the file almost as much as
ADDPFTRG does - is that really so?

Is there in that case another better way to dynamically switch
triggers on and off?

In such an environment, what is gained by having the work done in a trigger versus in the application(s) themselves? Pushing the business logic into the database via triggers, typically is done to ensure that the work will be performed for every triggered I\O *irrespective* of what the application is coded to do or not do, beyond that specific I\O request. Requiring the exclusive lock by CHGPFTRG ensures that the triggers can not be be disabled while the file is in use by any number of applications, thus ensuring that the intended business logic was being applied to every I\O until the change-requester obtained their exclusive allocation. Otherwise the logging\journal-entries might have to be reviewed to know which I\O activity had not been triggered, and then presumably required to have the intended business logic applied later, to each row according to each I\O action [for which the business logic was not triggered]; though according to design, the trigger would still get called for all existing opens that were performed when the trigger was active, because the trigger is defined in the active ODP.

Seems to me that if the expressed capability to disable and re-enable the triggers "at will" is required, then the application(s) should probably be making the decision about which additional business logic should be performed with that I\O. Or that same logic being used to decide which additional business logic should be performed with that I\O, could simply be deferred for invocation from within the triggers, such that the triggers would remain enabled and the triggered program would simply return with no additional action taken for that I\O when deemed appropriate by the added logic.?

Given none of that makes sense for the given scenario, for whatever reason [e.g. it just *has* to work that way], then I offer instead that... The application(s) using the file(s) should be designed with effective failover capability. The design should allow for the applications to be interrupted and stopped, to include closing the file(s) [and releasing other resources], and then reactivate [using the same or different files or possibly even a different database] as directed by the interrupter. That enables the opportunity for the Change Physical File Trigger request to complete at a clear boundary; the time at which the change-requester was able to obtain the exclusive lock because all applications had closed\unlocked the file(s).