Re: Where to put a trigger program...

There's certainly an argument for keeping triggers with their database objects, but I use the opposite.  I have multiple environments that share program objects but have different database libraries.  After studying Alan Campin's excellent trigger mediator design, I adopted a pared down version for our shop.  Any file that needs a trigger uses the same trigger which resides in the common library(*), which simply passes the event to a second program.  The second program routes the event based on the trigger buffer info (file, library, and so on).

1. I can change the router (the second program) without locking the files
2. I can change the business logic in multiple environments by deploying a single program change

Yes, I would have to reapply triggers after a library, but it's pretty simple.  I just need a list of physical files that I spin through that to apply the trigger. Since it's the same trigger program, it's pretty easy.

It's not everyone's cup of tea, but it works wonderfully here.

* Recently, I moved the trigger mediator from the common program library which was in the user library list to a library in the system library list.  But the concept remains the same.

On 3/17/2021 3:11 PM, James H. H. Lampert wrote:

On 3/17/21 1:04 PM, Brian Parkins wrote:

Do tell - why? (Just curious to learn.)

If a trigger program needs to be changed (unless it's not an actual trigger program, but a program called via a "trigger mediator" that's the actual trigger), then *all* locks on *any* file to which it is attached must be cleared before it can be recompiled.

That can be a pain in the butt at times.

--
JHHL