RE: CRTDUPOBJ of file with trigger renders trigger inoperative

Vern,

What's really annoying about the situation is that CRTDUPOBJ apparently
retrieves the SQL source of the trigger and creates a new trigger with
the same name in the new library to attach to the duplicated object.  (
I get the spool files from CRTSQLCI and CRTCMOD )

The only problem is the trigger has a status of *INOPERATIVE.

If there's some huge limitation that prevents and SQL table with an SQL
trigger from being duplicated with the trigger, why the heck go through
all the trouble?  So you can see that there was a trigger on the file
but to get a working one you have to manually drop and recreate it?
Shoot, just send me an escape message.

It feels as if I was the first guy to ever do this and wonder why it
didn't work.



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 
> vhamberg@xxxxxxxxxxx
> Sent: Wednesday, December 14, 2005 3:59 PM
> To: Midrange Systems Technical Discussion
> Subject: RE: CRTDUPOBJ of file with trigger renders trigger 
> inoperative
> 
> The differences between these things rests, to some extent, 
> in the attributes attached to the underlying object type. If 
> you DSPFD on a DDS-generated PF, there is not entry for SQL 
> type, whereas there is for a DDL-generated one. I would 
> think, as you seem to, Charles, that there is basically a 
> single code path for database stuff. Branches from it depend 
> on the various attributes found on the object. So it seems it 
> OUGHT to be possible to do similar processing for both native 
> and SQL objects - unless the SQL path, being probably tacked 
> on to the old native code path, goes so far afield as not to 
> be able to get home again.
> 
> Ah, sweet life! What a metaphor!
> 
> -------------- Original message -------------- 
> From: "Wilt, Charles" <CWilt@xxxxxxxxxxxx> 
> 
> > I'm aware of the performance differences. Which is one of 
> the reasons I 
> > chose to use a DDL table instead of a DDS file. 
> > 
> > However, same doesn't have to mean "exactly the same". When 
> it comes to 
> > DDL tables vs. DDS files, I'm think more along the lines of an OO 
> > polymorphic relationship. DDL tables and DDS files are the 
> "same" in 
> > the sense that a "new" DDL table can be used in place of a 
> "old" DDS 
> > file. I believe that IBM has been basically saying this. 
> > 
> > In any event, what my trigger does is add a record another 
> file when a 
> > record is added to the file with the trigger. 
> > 
> > I've tried duplicating the referenced objects, (another trigger the 
> > trigger reads a value from, a couple of SQL UDFs, and the table the 
> > trigger outputs to ) but it hasn't helped. 
> > 
> > In addition, IBM has copies of the source for the table, 
> the trigger, 
> > and the referenced objects, that I assume they've been 
> working with. 
> > 
> > 
> > 
> > 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 
> DeLong, Eric 
> > > Sent: Wednesday, December 14, 2005 10:57 AM 
> > > To: 'Midrange Systems Technical Discussion' 
> > > Subject: RE: CRTDUPOBJ of file with trigger renders trigger 
> > > inoperative 
> > > 
> > > Well, they're not precisecly the same thing any more..... 
> > > There were some 
> > > discussions about how DDL described files have a performance 
> > > edge over DDS 
> > > described files. It seems that DDL files validate field data 
> > > when it is 
> > > being written, while DDS files validate field data when it is 
> > > being read. 
> > > This sort of behavior would seem to mean that the object 
> > > types are not quite 
> > > the same. Perhaps a dump might reveal where the 
> difference lies.... 
> > > 
> > > There seems to be more to this than meets the eye. What is 
> > > your trigger 
> > > doing? The documentation that Elvis references seems to be 
> > > saying that some 
> > > object that's being referenced by the trigger is not 
> > > available in the new 
> > > target library..... 
> > > 
> > > Eric DeLong 
> > > Sally Beauty Company 
> > > MIS-Project Manager (BSG) 
> > > 940-297-2863 or ext. 1863 
> > > 
> > > 
> > > 
> > 
> > -- 
> > 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. 
> > 
> -- 
> 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.
> 
>