Re: Changing triggers

What we've done is use a generic trigger program to dump the changed record
information to a file and background program to process it based on a
control file. This allows a change of what is to be done with the data
whenever you want to and doesn't require any changes at the trigger level.
----- Original Message -----
From: Nelson, Jim (RCIS) <Jim.Nelson@RCIS-NET.COM>
To: <MIDRANGE-L@midrange.com>
Sent: Monday, March 27, 2000 10:20 AM
Subject: Changing triggers


> In our development environment, we are changing SOME trigger on SOME file
> almost daily.  To make such a change, the file that trigger is based on
must
> not have any locks.  This has become unworkable with the number of
> developers and functional test people involved.
>
> We are talking about creating completely generic triggers to call a stored
> procedure which will either run the activity intended or call one or more
> other stored procedures.  When a change was needed it would be made to
that
> front-end stored procedure.
>
> Before we get too deep into this, it would be nice to know if there are
any
> 'gotchas'.
>
> Has anybody else gone down this road?  Has it worked?  Anything we should
> keep in mind?
>
> Thanks,
> JN
>
> +---
> | This is the RPG/400 Mailing List!
> | To submit a new message, send your mail to RPG400-L@midrange.com.
> | To subscribe to this list send email to RPG400-L-SUB@midrange.com.
> | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
david@midrange.com
> +---
>

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---