Re: FILE TRIGGER

[Paul Tuohy <tuohyp@xxxxxxxxxxxxxxxxx>]

Duane,

Ken is referring to blocking in RPG - and this is something RPG can do 
all by itself, especially if a file is open for output.

i.e. RPG can block a number of records in a buffer before handing them 
over to the DBMS for processing.

Check out the BLOCK keyword for F specs for details.

BTW - not sure if this is the issue with the OPs trigger delay - just to 
clarify what Ken was referring to.

Regards

Paul Tuohy
ComCon
www.comconadvisor.com 
www.systemideveloper.com 





Christen, Duane wrote:
> 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.
>