m_denise
asked on
Data from one database not transferred to another database (using DB LINK) if user is not OBJECT OWNER
Hi.
I am using Oracle Forms in my application. Users for the application are setup to be either an 'OBJECT OWNER' or an 'APPLICATION USER'.
I have a screen that calls a package to transfer data from the current database to another database, using a PUBLIC DATABASE LINK.
Unfortunately when the user that processed the data transfer is NOT THE OBJECT OWNER (i.e. just an APPLICATION USER), I get the error: "ORA-02070: database does not support in this
context". I think it may be because my table has a default of SYS_CONTEXT('APP','BRANCH' ) in one of its fields. Unfortunately, I need this default for the forms processing.
I have also tried using the OBJECT OWNER to do the processing and it is working fine. Unfortunately, there may be cases when the user to do the processing is not the object owner, so I need to have this problem fixed.
Please help. This is kinda urgent.
Thanks.
I am using Oracle Forms in my application. Users for the application are setup to be either an 'OBJECT OWNER' or an 'APPLICATION USER'.
I have a screen that calls a package to transfer data from the current database to another database, using a PUBLIC DATABASE LINK.
Unfortunately when the user that processed the data transfer is NOT THE OBJECT OWNER (i.e. just an APPLICATION USER), I get the error: "ORA-02070: database does not support in this
context". I think it may be because my table has a default of SYS_CONTEXT('APP','BRANCH'
I have also tried using the OBJECT OWNER to do the processing and it is working fine. Unfortunately, there may be cases when the user to do the processing is not the object owner, so I need to have this problem fixed.
Please help. This is kinda urgent.
Thanks.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Seems I misunderstood you.
So, you have a package that has a procedure that works fine
under the domain of the user 'OBJECT OWNER' ,
but fails if it runs under the domain of 'APPLICATION USER'.
I hope the owner of the procedure is 'OBJECT OWNER' ,
Try this:
as 'OBJECT OWNER' :
SQL>grant execute on procedure_name to 'APPLICATION USER';
The idea is that the procedure will be invoked by 'APPLICATION USER'
but will run under the domain of 'OBJECT OWNER' .
So, you have a package that has a procedure that works fine
under the domain of the user 'OBJECT OWNER' ,
but fails if it runs under the domain of 'APPLICATION USER'.
I hope the owner of the procedure is 'OBJECT OWNER' ,
Try this:
as 'OBJECT OWNER' :
SQL>grant execute on procedure_name to 'APPLICATION USER';
The idea is that the procedure will be invoked by 'APPLICATION USER'
but will run under the domain of 'OBJECT OWNER' .
ASKER
Actually, the procedure itself works fine whether I run it with 'OBJECT OWNER' OR 'APPLICATION USER'.
In my procedure, I have this command to transfer data from the current database to another database using a DB Link:
EXECUTE IMMEDIATE 'INSERT INTO DEST_TABLE@'|| v_dblink ||
' SELECT * FROM SOURCE_TABLE WHERE TRAN_DATE = :x'
using v_syst_date;
This command is what does not work when the 'APPLICATION USER' is running the procedure.
In my procedure, I have this command to transfer data from the current database to another database using a DB Link:
EXECUTE IMMEDIATE 'INSERT INTO DEST_TABLE@'|| v_dblink ||
' SELECT * FROM SOURCE_TABLE WHERE TRAN_DATE = :x'
using v_syst_date;
This command is what does not work when the 'APPLICATION USER' is running the procedure.
ASKER
I have tried creating and using a SYNONYM for the SOURCE_TABLE as you said:
CREATE OR REPLACE PUBLIC SYNONYM SOURCE_TABLE_SYN FOR '||
v_user||'.DEST_TABLE@'||v_ dblink
I used it in the same procedure thru:
EXECUTE IMMEDIATE 'INSERT INTO SOURCE_TABLE_SYN SELECT * FROM SOURCE_TABLE WHERE TRAN_DATE = :x'
using v_syst_date;
I still get the error: "ORA-02070: database does not support in this context" with that command when the procedure is run in the application by the 'APPLICATION USER'.
CREATE OR REPLACE PUBLIC SYNONYM SOURCE_TABLE_SYN FOR '||
v_user||'.DEST_TABLE@'||v_
I used it in the same procedure thru:
EXECUTE IMMEDIATE 'INSERT INTO SOURCE_TABLE_SYN SELECT * FROM SOURCE_TABLE WHERE TRAN_DATE = :x'
using v_syst_date;
I still get the error: "ORA-02070: database does not support in this context" with that command when the procedure is run in the application by the 'APPLICATION USER'.
Upgrade the DB at least to 9.2.0.5 -----> bug 3277927!
ASKER
This is the current version of my database
-------------------------- ---------- ---------- ---------- --------
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bi
PL/SQL Release 10.2.0.1.0 - Production
CORE 10.2.0.1.0 Production
TNS for Solaris: Version 10.2.0.1.0 - Production
NLSRTL Version 10.2.0.1.0 - Production
--------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bi
PL/SQL Release 10.2.0.1.0 - Production
CORE 10.2.0.1.0 Production
TNS for Solaris: Version 10.2.0.1.0 - Production
NLSRTL Version 10.2.0.1.0 - Production
ASKER
I have tried to use a FOR LOOP for this problem and it's working if I explicitly hard-code the DB LINK name.
However, I have to use a variable for the DB LINK name because I cannot predict what the name will be. When using a variable for the DB LINK, I can't make my explicit insert statement work.
So instead, I explicitly inserted into the SYNONYM using the FOR LOOP:
FOR i in table_rec (date) --this cursor already selects my needed records
LOOP
INSERT INTO TABLE_SYNONYM
VALUES (k.value1, k.value 2);
COMMIT;
END LOOP;
However, I have to use a variable for the DB LINK name because I cannot predict what the name will be. When using a variable for the DB LINK, I can't make my explicit insert statement work.
So instead, I explicitly inserted into the SYNONYM using the FOR LOOP:
FOR i in table_rec (date) --this cursor already selects my needed records
LOOP
INSERT INTO TABLE_SYNONYM
VALUES (k.value1, k.value 2);
COMMIT;
END LOOP;
ASKER
Because I have not used that before in any of my applications yet.
Thanks.