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).
