RE: CRTDUPOBJ of file with trigger renders trigger inoperative

Charles,

 I would like to see an additional parm or two on the CRTDUPOBJ relating to
the SQL and trigger stuff.  That way we can (and should!) have control over
what gets copied and activated.

 -mark

Original Message:
-----------------
From: Wilt, Charles CWilt@xxxxxxxxxxxx
Date: Thu, 15 Dec 2005 08:15:23 -0500
To: midrange-l@xxxxxxxxxxxx
Subject: RE: CRTDUPOBJ of file with trigger renders trigger inoperative


Well the only appropriate action is to drop and recreate the trigger.

But at the very least you could use the Retrieve Database File
Description (QDBRTVFD) API to get all the information needed to recreate
the trigger.  But holy crap, have you looked at that sucker?  I'm not
sure I'm paid enough to tackle that puppy. <grin>

I got a new reply from IBM:
I discuessed this more with the developer.  The short of it is, it will 
always be inoperative.  This is for your protection.  There is no way of
knowing if the files referenced in the trigger program are still        
accurate or not.  Therefore, to prevent possible unwanted actions (i.e. 
test file trigging a program that updates production files), they set it
to inoperative.                                                         
                                                                        
If you do an OPNDBF *ALL for the file, you will see message CPD502B that
lists the trigger as inoperative nd show the cause as:                  
                                                                        
A trigger can be inoperative when a create duplicate object of a file   
with any triggers or restore object of a file with any triggers is to a 
library other than the original library.                                
                                                                        
Thanks for using the IBM Rochester Support Center!!                     


Ok that's fine mom, but how about an easy way to turn the trigger back
on rather than dropping and recreating it?  Not to mention that
according to the docs, if every referenced object is in the new library
the trigger is supposed to use those instead of the originals..but that
didn't happen.

Part of my problem is that I don't have the source on the same system
where I'm running the CRTDUPOBJ.  Even if I did, the source I have is
written to work with our CMS and includes a replacement variable for the
library where the object is to be created.  I really don't want to have
to try an maintain two separate copies of the source for any triggers
whose files I may want to run a CRTDUPOBJ on.

Looking at IBM's reply and the QDBRTVFD API, it would probably be easier
to write an MI program that flips the *OPERATIVE/*INOPERATIVE bit on the
stupid trigger(file?). 



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 rob@xxxxxxxxx
> Sent: Wednesday, December 14, 2005 4:33 PM
> To: Midrange Systems Technical Discussion
> Subject: RE: CRTDUPOBJ of file with trigger renders trigger 
> inoperative
> 
> Possible workaround?  Is there some api to retrieve the name(s) of 
> inoperative triggers and perform appropriate actions?
> 
> Rob Berendt


--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .