I accidentally permanently deleted this on-target post (copied from
archives):
<Peter Dow>
I think the problem is that it doesn't know what the authority of the
trigger program is because it doesn't have authority to the library the
trigger program is in. Something like having lots of money but you can't
spend it because it's locked up and you don't have the key.
</Peter Dow>
Right on the point! My stored procedure went to the vault with a
borrowed key. The DBMS recognized the key as borrowed and would not
honor it. My solution is to have the stored procedure request a teller
(batch job with *ALL authority to the file) that does own a valid key to
access the vault, put in the data in the vault and give the stored
procedure a receipt.
But it looks like Ed Fishel has a recommendation that may supplant this
work around.
Thanks everyone for your thoughts.
Roger Mackie
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[
mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Elvis Budimlic
Sent: Tuesday, April 03, 2007 11:41 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Adopted authority and triggers
Way I understood, problem was that user didn't have authority to the
library where trigger program resides.
Celebrating 10-Years of SQL Performance Excellence
-----Original Message-----
Subject: RE: Adopted authority and triggers
As far as USEADPAUT goes, they could/should ignore system-state programs
and only adopt from user state programs, that would solve that problem,
no? Regardless, unless I misunderstood, the original poster wasn't able
to get the USRPRF(*OWNER) option to work either, correct?
-Walden
midrange.com
