When session is altered to the schema that owns the object, schema qualification isn't needed. Our reason for eliminating the use of public/private synonyms (where possible) is from a performance point of view on the library cache. Steve Adams explains it best http://www.ixora.com.au.
Alter session is working for all of our clients except those using PL/SQL. I'm stumped. Darlene Marley wrote: > > The view will always have to have the schema qualification without a > synonym: > select from y.view_name. > I use roles, synonyms and stored procedures extensively in my application > and the combination has worked well so far. Is there a reason in your case > for not using synonyms? > Darlene > > Suzy Vordos wrote: > > > I understand that privileges granted via role are disabled within stored > > procedures, so privileges need to be granted explicitly to the user, > > else PLS-00201 error is returned. > > > > We have a situation where user X connects to the database, executes > > select against user Y's view using PL/SQL, and receives the PLS-00201 > > error. User X has explicit select grants to Y's view, not grants via > > role. We are using a logon trigger which sets X's current_schema user > > Y. Here's what it looks like: > > > > grant create session to user X; > > grant select on Y.view_name to X; > > > > X connects to database > > login trigger execs 'alter session set current_schema=Y' > > PL/SQL code selects from view_name, PLS-00201 error returned > > > > To eliminate this error, the workaround was to create a public synonym > > (ick) with select grants to user X. > > > > The client is executing PL/SQL code within their application, not > > executing a PL/SQL code stored in the database (if that makes a diff). > > > > The whole point of using the logon trigger was to eliminate the use of > > public/private synonyms. I'm missing where user X inherited privs via > > role when we didn't grant privs via role. Is it related to altering > > current_schema, or is it something more obvious?? > > > > Thanks, > > Suzy > > -- > > Please see the official ORACLE-L FAQ: http://www.orafaq.com > > -- > > Author: Suzy Vordos > > INET: [EMAIL PROTECTED] > > > > Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 > > San Diego, California -- Public Internet access / Mailing Lists > > -------------------------------------------------------------------- > > To REMOVE yourself from this mailing list, send an E-Mail message > > to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in > > the message BODY, include a line containing: UNSUB ORACLE-L > > (or the name of mailing list you want to be removed from). You may > > also send the HELP command for other information (like subscribing). > > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.com > -- > Author: Darlene Marley > INET: [EMAIL PROTECTED] > > Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 > San Diego, California -- Public Internet access / Mailing Lists > -------------------------------------------------------------------- > To REMOVE yourself from this mailing list, send an E-Mail message > to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in > the message BODY, include a line containing: UNSUB ORACLE-L > (or the name of mailing list you want to be removed from). You may > also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Suzy Vordos INET: [EMAIL PROTECTED] Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists -------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
