I realized I had not copied the list... On Thu, Feb 21, 2008 at 12:42 PM, Stephen Andert <andert@xxxxxxxxx> wrote: > Don, > > OK, now I see what you are asking. We do have a logon trigger, but it > only checks if the user is SYS or SYSTEM and if so logs an entry to a > table. No roles are granted or set using this trigger. > > > On Thu, Feb 21, 2008 at 12:30 PM, Don Seiler <don@xxxxxxxxx> wrote: > > > Sometimes a login trigger would check the context of the login to see > > if the login is coming from a certain IP address/range or hostname and > > OS username. That's why I asked if there was such a mechanism in > > place on your instance. > > > > Don. > > > > On Thu, Feb 21, 2008 at 1:27 PM, Stephen Andert <andert@xxxxxxxxx> > > wrote: > > > Don, > > > > > > Both of us (myself and a DEVeloper in Chicago) log in to TOAD or > > SQL*Plus > > > with the same USER_A database user and password. We execute the same > > > procedure and get different results. Not sure how we could have a > > > difference in roles or privileges, but the GRANT is done directly to > > the > > > user. > > > > > > Thanks > > > > > > > > > > > > On Thu, Feb 21, 2008 at 12:18 PM, Don Seiler <don@xxxxxxxxx> wrote: > > > > Is it the USER that has the execute privs, or some role granted to > > the > > > > user? If so, is the role a default role? If not default, is there > > a > > > > logon trigger that conditionally sets the role upon user login? > > > > > > > > Don. > > > > > > > > > > > > On Thu, Feb 21, 2008 at 12:55 PM, Stephen Andert <andert@xxxxxxxxx> > > wrote: > > > > > > > > > > > > > > > > > > > > > > USER_A cannot execute a procedure owned by USER_B when one person > > logs > > > in. > > > > > USER_A can execute a procedure owned by USER_B when a different > > person > > > logs > > > > > in. > > > > > > > > > > One person is in one city and the other is in a different city, > > but in > > > TOAD, > > > > > both users can "see" the procedure when browsing the procedures of > > > USER_B. > > > > > > > > > > Furthermore, this is only the case in one environment (DEV) and > > works > > > > > normally in other environments (i.e. QA) > > > > > > > > > > I have confirmed (in TOAD and SQL*Plus) that USER_A has EXECUTE > > privs on > > > the > > > > > procedure granted by USER_B. > > > > > > > > > > Help. What else can I try? > > > > > > > >