vanishing triggers? (v6 on os/390) - SOLVED

[login to unmask email]

vanishing triggers? (v6 on os/390) - SOLVED
The useradmin group didn't have creatin privilege for the schema being
named for the trigger - even though the schema was the same name as the
database that the tables were being created in ( and useradmin group is the
dbadm ). There simply was no error message being generated for the
condition/combination of circumstances.

Thanks all,

"Dr. Michael
Ebert" To: [login to unmask email]
<[login to unmask email] cc:
ET> Subject: Re: vanishing triggers? (v6 on os/390)
Sent by: DB2 Data
Base Discussion
<[login to unmask email]

12/10/2002 08:53
Please respond to
DB2 Data Base
Discussion List

I would assume the user is not COMMITting his CREATE TRIGGER statement.
Probably there is some garbage after the CREATE in the input.

Dr. Michael Ebert
DB2 Database Administrator
aMaDEUS Data Processing
Erding / Munich, Germany

Has anyone come across this scenario before ?

All through SPUFI -

As the install sysadm, I can create and drop triggers with impunity - as it
should be.
With "set current sqlid = <useradmin>" I can create and drop triggers on
the tables that useradmin has the privileges on - also as it should be.
When the user who is useradmin logs in he can create the trigger with a
normal response - however, nothing shows up in the systriggers table and
the trigger doesn't really exist. No error message to the useradmin,
nothing in the output of any of the db2 started tasks, nothing anywhere in
the user's tso session output, nothing on syslog pertaining to db2 during
this time.

Any ideas ? An error message would be helpful but I can't even get that.


Bruce Lightsey
Mississippi Dept. of Information Technology Services
301 N. Lamar St., Suite 508
Jackson, Ms 39201-1495

Walter Jani&#223;en

Re: vanishing triggers? (v6 on os/390)
(in response to lightsey@ITS.STATE.MS.US)

A long time ago, we had the same problem. If a user, who is not sysadm
created a trigger, say using DSNTEP2, all looked o.k. but no entry was made
in the DB2 catalog. We reported this problem to IBM and I think they solved
it, but I don't which PTF it is. May be ypu can look it up in the APAR