Calling PL/SQL Procedure In Another Schema Gives Unexpected Result

Question

I have a SQL Script that does this:
conn pnr/<password for user pnr>;
set serveroutput on;
exec vms.disable_all_fk_constraints;
SELECT owner, constraint_name, status FROM user_constraints WHERE constraint_type = 'R';
and the disable_all_fk_constraints procedure that is owned by user 'vms' is defined as:
create or replace
procedure disable_all_fk_constraints is
v_sql   VARCHAR2(4000);
begin
dbms_output.put_line('Disabling all referential integrity constraints.');
for rec in (SELECT table_name, constraint_name FROM user_constraints WHERE constraint_type='R') loop
dbms_output.put_line('Disabling constraint ' || rec.constraint_name || ' from ' || rec.table_name || '.');
v_sql := 'ALTER TABLE ' || rec.table_name || ' DISABLE CONSTRAINT ' || rec.constraint_name;
execute immediate(v_sql);
end loop;
end;
When I run the SQL script, the call to vms.disable_all_fk_constraints disables the FK constrains in the 'vms' schema, whereas I wanted it to disable the FK constraints in the 'pnr' schema (the invoker of the procedure). I know that I could make this work by copying the disable_all_fk_constraints procedure to the 'pnr' schema and calling it as "+exec disable_all_fk_constraints;+" from within the SQL script but I want to avoid having to duplicate the PL/SQL procedure in each schema that uses it.
What can I do?
Thank you

Answer 1

You have two issues to solve.
First you need to write a packaged procedure that works with INVOKER rights. The default is DEFINER rights.
The difference is excatly what you need. Usually the package has the rights from the schema where it is defined (=Definer rights). In your case schema VMS. Whereas you need the privileges from the user that calls the package (PNR).
=> Check out the documentation for INVOKER rights
The second problem is that the view "user_constraints" will not give the results you expect when called from inside a procedure in another schema. An alternative could be to use the view DBA_CONSTRAINTS with a filter on the owner (where owner = 'PNR'). Not sure if there are other working possibilities. Well you could create a list of constraint names that you want to disable, instead of creating the list dynamically.
And you could have another potential disaster creeping up upon you. If you run this thing, then at this moment you don't have any referential integrity anymore. You can't be sure that you can create the FKs again after this action. This is EXTREMLY DANGEROUS. I would never ever do this in any kind of production or test database. I would be very careful when I do it on a development database.