James H. H. Lampert wrote:

IF it could be done while there were users in the file.

Unfortunately, I just found out that it can't. So it's no more useful
than just adding or removing the trigger (indeed, worse, because
PRTTRGPGM doesn't indicate anything about whether a trigger is
deactivated), and looks like the result of somebody in Rochester having
WAAAYY too much time on his or her hands.

And in this case, unless there's something else besides CHGPFTRG that
will put triggers into a disabled state, somebody at the customer went
to a LOT of trouble to turn Workflow off while making it LOOK like it
was still turned on.

Not that you want people to disable your trigger during production
hours, but for those times when you, using a trigger mediator program is
a good solution. Basically, you write a thin shell that is registered
with ADDPFTRG. The shell reads the trigger buffer and calls a separate
program to do the actual work of the trigger. When you need to
recompile the trigger, you can, because you aren't touching the shell
(which shares locks with the PF).

In the shell you can check a data area or what have you to tell whether
you actually want to fire the processing logic or not.
--buck

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2020 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].