Change schema runtime in procedure

Question

Hello friends,
I have one query in procedure. I have same table with same structure and name in more than 10 schema. I want to access these table records dynamically using procedure.
I want to change schema name in procedure.
Please check below PL/SQL code i have wrote.
declare
     cursor c1 IS
     select deptno,dname,loc from &schema..dept;
begin
     for rec in c1
     loop
          dbms_output.put_line(rec.deptno || ' ' || rec.dname || ' ' || rec.loc);
     end loop;
end;
I want same functionality using procedure. Please check procedure code below:
create or replace procedure diff_schema (schema_name IN varchar2)
Declare
     cursor c1 IS
     select deptno,dname,loc from schema_name.dept;
AS
begin
     for rec in c1
     loop
          dbms_output.put_line(rec.deptno || ' ' || rec.dname || ' ' || rec.loc);
     end loop;
end;
but it returns error.
Please help me to solve this issue.
Pradip Patel

Answer 1

BluShadow wrote:
Venkadesh wrote:
Agree..
Hope this work.
create or replace procedure r_test (p_schema in varchar2)
is
v_rc sys_refcursor;
v_all emp%rowtype;
begin
open v_rc for 'select * from '||p_schema||'.emp';
loop
fetch v_rc into v_all;
exit when v_rc%notfound;
dbms_output.put_line(v_all.ename);
end loop;
close v_rc;
end;
That still assumes that the emp table exists in the schema in which the procedure is compiled because you have:
v_all emp%rowtype;Essentially what the OP is asking for indicates that whereve the procedure is defined is going to need to know the structure of the tables it's going to use otherwise everything about it would need to be dynamic.
We have a process on one of our databases that has a similar setup, where there are several schema's all containing the same table structure, but different data, and we need a central setup of code that can process each of those as required.
For us we looked at it from a different perspective. Rather than having the central procedure try and access all the other schemas, for which it would need to know which schemas it has to access etc. and because sometimes some of those schemas should be excluded from the process if they have had an issue with their data being populated (it's a regular job to repopulate them and determine changes on them etc. - a bit of an ETL task really), we leave it up to the individual schemas to determine when the processing is necessary (i.e. when they each know their own data is ready to be processed). The advantage of that is that the central procedure's those schemas use all use the AUTHID CURRENT_USER, so the central schema just has a blank copy of the tables so the code can compile, but when the other schemas call the procedure, they are running the code against their own tables because of the AUTHID setting. It avoids any dynamic coding, or any (mis/ab)use of ref cursors, and it gives the flexibility that each schema is in control of it's own destiny, and other schemas can be added or removed as necessary without having to have some central control mechanism to know which schemas need processing.Thank you Blu,i'm learning lot of things from you...you are a champion