I agree. The RPG counterpart that receives trigger buffer in my example
has the before and after images. No addition querying is required if all
the data you need is in the buffers. In the case of the code I provided,
the RPG program looks in the employee file (not the one being
triggered), and updates the work order cost in the buffer.
I was simply supplying the example of a CL program receiving the
buffers.
Now, actually using the trigger buffers in CL would be interesting,
never needed/wanted to do it.
Loyd Goodbar
Senior programmer/analyst
BorgWarner
TS Water Valley
662-473-5713
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[
mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Thursday, April 26, 2007 13:12
To: Midrange Systems Technical Discussion
Subject: RE: Brainstorming
But you're forgetting the whole point of a trigger!
Ok, now for a little history...
Back in the dark ages one would have the Never Ending Program (NEP) that
would occasional query the database for changes. If it found any, it
would
perform the actions you are talking about. I have a coworker who
installed one of these in the last year or two despite my STRONG
encouragement to use a trigger.
Then they came up with triggers. Why do you insist on querying the
database for changes? The G..D... trigger has the changes in it. You
do
not need to restore a before and after image someplace to see what was
changed. They are passed as parameters to the trigger. Please see the
two data structures NEW and OLD in the sample I posted.
In your technique if someone updates three PO's you are going to query
the
whole stinking database 3 times looking for any changes. However, if
you
use a trigger you would already know which particular PO got updated
during the trigger by looking at the fields in the datastructure NEW.
If
you wanted to know if the PO status field changed you could compare
NEW.PSTAT against OLD.PSTAT (we're running BPCSCD also).
Rob Berendt
midrange.com
