Getting PLS-00201 when trying to access another schema table

Question

I want to clean some data on SCHEMA_ADM and SCHEMA_DAT tables, but, my procedure need to be stored on SCHEMA_DAT and will be called by SCHEMA_APP. I did the procedure like this:

create or replace PACKAGE BODY "PKG_CLEANING_THE_MESS"
AS
PROCEDURE PRC_DELETE_DATA (some variables...)
AS
    TYPE fooTableType
    IS TABLE OF FOO_TABLE.ID%TYPE; --TABLE ON SCHEMA_DAT. Works fine!
    fooTable fooTableType;

    TYPE xyzTableType
    IS TABLE OF XYZ_TABLE.ID%TYPE; --TABLE ON SCHEMA_ADM. The problem is here!!!
    xyzTable xyzTableType;
    ...
END PRC_DELETE_DATA;
...
END PKG_CLEANING_THE_MESS;

When I try to compile that, give me

PLS-00201: identifier 'XYZ_TABLE' must be declared.

I tried "SCHEMA_ADM"."XYZ_TABLE" instead of just "XYZ_TABLE", but didn't works too. The SCHEMA_DAT has a SIUD role to SCHEMA_ADM and a SYNONYM to XYZ_TABLE, but doing research I found that stored procedures can't use the grant of roles. But I didn't found any way to give the grants on the PROCEDURE to compile without errors and to guarantee that SCHEMA_APP also can call the procedure. Any help on that? Thanks!

EDIT: I found this similar question , asked 4 years ago, but without a conclusive answer :/

Answer 1

The checklist for this error should be something like:

1. Does table XYZ_TABLE exist? (Did you spell it right? Is it actually named in double-quotes as something like "xyz_table" or "XYZ Table" ?)
2. Is it in the expected schema, SCHEMA_ADM ?
3. Are privileges such as SELECT granted directly to the package owner, SCHEMA_DAT ?
4. Is there a private or public synonym with the expected name? (eg there might be a synonym X for table Y , but the code refers to Y .)
5. Or, is the code prefixing it with the schema name eg SCHEMA_DAT.XYZ_TABLE ?
6. Is there a package or type with the same name as the schema ( SCHEMA_DAT )? This could create a naming conflict where the compiler finds the package instead of the schema, and then looks in that for something called XYZ_TABLE .

Your requirements may vary, but it's usually better to create a synonym than to hardcode the schema name (less to type, more flexibility if things change), and private synonyms are preferable to public synonyms (security, as they don't broadcast your schema structure, and more flexible in case you want to direct different users to different objects, or add another schema later with different requirements).