RE: Triggers

You can share it if you'd like but, the info you posted here is straight
out of the infocenter...nothing new.

The file was created with SQL, as was the trigger.

When CRTDUPOBJ is used, it duplicates the file and the trigger into the
new library.  In other words, a DSPFD shows the trigger on the file as
being in the new library with the duplicated file.  Not only does the
file description point to a new trigger, but there's a new *SRVPGM
object, containing the actual code for the SQL trigger, created in the
new library.

As mentioned before, I've tried making sure that everything reference by
the trigger is also in the library.  It hasn't help, the trigger on the
new file always has a status of *INOPERATIVE.

So far, IBM's answer is "You can't use CRTDUPOBJ on an SQL table with an
SQL trigger."


Charles Wilt
--
iSeries Systems Administrator / Developer
Mitsubishi Electric Automotive America
ph: 513-573-4343
fax: 513-398-1121
  

> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx 
> [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Mike savino
> Sent: Wednesday, December 14, 2005 1:44 PM
> To: MIDRANGE-L@xxxxxxxxxxxx
> Subject: Triggers
> 
> I haven't followed this thread all the way through, so 
> apologies if someone 
> has already mentioned this....
> 
> This straight from IBM, though I don't remember exactly where 
> I found it:
> 
> =============================================================
> 
> Create Duplicate Object (CRTDUPOBJ)
> *     When a physical file and its trigger program are 
> originally in the same 
> library, the trigger program library will always be changed 
> to the new 
> library, even if the trigger program doesn't exist in the new 
> library. In 
> addition, the following holds true:
> o     If the CRTDUPOBJ command is duplicating both the 
> physical file and its 
> trigger program to a new library, then the new trigger 
> program will be 
> associated with the new physical file.
> o     If the CRTDUPOBJ command is duplicating only the 
> physical file, then the 
> trigger program with the same program name in the TO library will be 
> associated with the new physical file. This is true even if 
> there is no 
> trigger program by that name in the TO library. The library 
> of the trigger 
> program will be changed.
> o     If the CRTDUPOBJ command is duplicating only the 
> trigger program, then the 
> new trigger program will not be associated with any physical files.
> *     When a physical file and its trigger program are 
> originally in different 
> libraries:
> o     The old trigger program will be associated with the new 
> physical file. 
> Even though the new physical file is duplicated to the same 
> library as the 
> trigger program, the old trigger program will still be 
> associated with the 
> new physical file.
> 
> ============================================================
> 
> So my question would be... Does the new file point to a 
> Trigger Program that 
> actually exists ??  I've got a document with a whole list of 
> "Gotchas" 
> regarding Triggers that I'd be happy to share.  The info is 
> about 2 years 
> old so hopefully no drastic changes since then.
> 
> 
> Mike
> 
> 
> -- 
> 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.
> 
>