>> If a file is restored, does it fire the trigger for each record
>> restored? - i.e. should I remove the trigger before and re-add it
>> after, as part of the process of restoring the file?

>> if a file with a trigger is restored, should the trigger be restored
>> with it - i.e. should the trigger reside in the same library as the
>> file (TRGLIB on ADDPFTRG command)?  or does it matter?

I sent the following on another question on triggers. The mediator, also, 
solves the restore problem because it is what is restored, not the actual 
program and, yes, the trigger program should be in the library of the data 
file. That is where the trigger mediator is normally installed. Since the 
trigger mediator calls service programs, where they are located is up to you. 

>> We think a very good architecture for triggers is to make a CL program the
>> actual trigger program that calls an RPG program to do the work, passing the
>> appropriate parameters.  That allows you to modify the RPG program without
>> having to remove & add the trigger on the file.

I see all kinds of problems with that, the first being that CL programs have to 
be loaded every time they are called. Lot of overhead.

I have a much better solution called a Trigger Mediator. The trigger mediator 
lives between the data base and the trigger service program. Using the trigger 
mediator, you can instantly add or remove tables from triggers and instantly 
add or remove all tables from triggers. The trigger mediator program itself 
never needs to be modified. Everything is table driven. The best part to me is 
that everything is extremely fast and you can modify the trigger service 
programs without bringing down the entire system. 

I would be glad to send you a copy of the trigger mediator and the associated 
programs to maintain the trigger tables if you want to use it. 

This thread ...


Return to Archive home page | Return to MIDRANGE.COM home page