Re: SQL Triggers where Production and Test on Same iSeries

On 10 Apr 2013 09:41, CRPence wrote:

The SQL uses a file in QTEMP to recreate a since-invalidated SQL
TRIGGER; effectively a C compile of the source for the TRIGGER.
<<SNIP>>

I was confusing the file being created in QTEMP with the compile-time
activity. The issue seems instead to be related to the trigger
TRANSITION TABLE with naming QTRG######; the compiling files are QSQLSRC
and QSQLT##### files in QTEMP. Thus my reference to inoperable trigger
is probably not germane. Hmmm [note to self mainly], for whatever
reason, I thought transition tables were never created except with
statement-level triggers.

I think the problem is purely a run-time issue with two [effectively]
identical trigger programs being run in the same job, and probably due
to the routing step having ended but the job and the contents of QTEMP
remain. To the SQL the job may appear to be new in most every way but
whatever is [what the SQL created] in QTEMP; i.e. the SQL is probably
not fully /routing step/ aware. Again, probably a defect issue [unless
there is some doc that a new routing step is a restriction]... but I
will look further at the recreates anyhow, primarily for what might be a
circumvention, and secondarily to provide the recreate script to be
submitted with a PMR.

I have reproduced the problem [on v5r3] and am working on a
fully-resolved [i.e. no variables in the] script.

--
Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.