RE: FILE TRIGGER -- RPG400-L

Ken

Unless you are writing the blocking mechanism with your own code this is not valid. The blocking is done by the DBMS and the trigger is fired on each I/O.

IBM i 6.1 Information Center > Database > Reference > SQL reference > Concepts > Tables > Triggers
"The trigger granularity defines whether the actions of the trigger will be performed once for the statement or once for each of the rows in the set of affected rows."

Set granularity is only allowed with an SQL trigger (CREATE TRIGGER) and not with ADDPFTRG which calls a program for each and every record.

If you used set granularity for an SQL trigger I would still bet that an HLL I/O operation would fire the trigger for that row, as RPG and other HLLs don't I/O record sets, only one row at a time.

Duane Christen

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Ken Sims
Sent: Friday, December 03, 2010 9:52 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: FILE TRIGGER

Sorry Duane, but no, that does NOT make sense. When a file is
blocked, the program holds the records in its own storage and does not
call database management until it is ready to write the block to the
file.

(This is all irrespective of when records are actually written to some
type of permanant media.)

On Fri, 3 Dec 2010 08:08:10 -0600, "Christen, Duane"
<Duane.Christen@xxxxxxxxxx> wrote:

Ken;

Your whole statement is incorrect, sorry.

A trigger fires at one of two times. Before the record is inserted/updated/deleted/read to the buffer or after the record is inserted/updated/read from the buffer, irrespective of when the buffer is "written" to disk/ssd/mainstore.

When you do a Write/Update/Delete/Read (in RPG or SQL or any language) the trigger has been called either just after control is given to the DBMS or just before it returns to the statement following the Write/Update/Read. Assuming no obvious errors like no record exists to be deleted/updated/read, writing a record with a duplicate key value in an index in the table or built on index.

So barring certain errors (a trigger can throw errors to the DBMS which can be percolated to the "calling" program etc...) when you perform I/O to a table with a trigger defined for that I/O action the trigger will have fired by the time control is returned to the "calling" program.

Make sense?

Duane Christen

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Ken Sims
Sent: Thursday, December 02, 2010 3:49 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: FILE TRIGGER

Hi Bryan -

On Thu, 2 Dec 2010 13:59:51 -0500, "Bryan Mangan"
<bryanm@xxxxxxxxxxxxxxxxxxx> wrote:

I have file with a trigger program attached to it and when a record is
written to this file it is suppose to execute the trigger. Once the
record is written it take a good 3 to 5 minutes to execute the trigger.
Any ideas would be appreciated.

Is record blocking taking place? If so, the trigger isn't going to
fire until the program writes out the block of records (when the block
is full, the file is closed, or the writing is forced), at which point
it is going to fire repeatedly for each record in the block.

You do NOT need to mess with the force write ratio. The records don't
have to be written to permanent storage, but they do have to be handed
off to database management by the program.

Ken
Opinions expressed are my own and do not necessarily represent the views
of my employer or anyone in their right mind.

Ken
Opinions expressed are my own and do not necessarily represent the views
of my employer or anyone in their right mind.