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.