I am creating a table (here below is the code) - this is executed through some script on unix. The script also creates some synonyms (not sure what/how):
drop table BNS_SAA_MESSAGES;
CREATE TABLE BNS_SAA_MESSAGES
(
HostNumber varchar(50) NOT NULL,
SAAMessage varchar(2048) NOT NULL,
PRIMARY KEY (HostNumber)
);
I'm getting the following error:
Processing bns_saa_messages
cat: cannot open bns_saa_messages.sql
Commit complete.
GRANT SELECT ON bns_saa_messages TO RL_ORDFX_RPT
GRANT SELECT ON bns_saa_messages TO RL_ORDFX_RPT
*
ERROR at line 1:
ORA-01775: looping chain of synonyms
GRANT INSERT ON bns_saa_messages TO RL_ORDFX_RPT
GRANT INSERT ON bns_saa_messages TO RL_ORDFX_RPT
*
ERROR at line 1:
ORA-01775: looping chain of synonyms
GRANT UPDATE ON bns_saa_messages TO RL_ORDFX_RPT
GRANT UPDATE ON bns_saa_messages TO RL_ORDFX_RPT
*
ERROR at line 1:
ORA-01775: looping chain of synonyms
GRANT DELETE ON bns_saa_messages TO RL_ORDFX_RPT
GRANT DELETE ON bns_saa_messages TO RL_ORDFX_RPT
*
ERROR at line 1:
ORA-01775: looping chain of synonyms
create public synonym bns_saa_messages for ORDMSO.bns_saa_messages
create public synonym bns_saa_messages for ORDMSO.bns_saa_messages
*
ERROR at line 1:
ORA-00955: name is already used by an existing object
Commit complete.
I googled for ORA-01775: looping chain of synonyms and it seems to mean that a something was removed but there is a pointer to it. I'm guessing it happens during select from 'things' that do not exist anymore. Not sure if these things are tables or something else. This is what I gathered from my research.
Any idea how to create my tables? I tried to execute multiple times the SQL code, but to no avail - I get the same error every time.
Also the table is not created:
SQL> select * from bns_saa_messages;
select * from bns_saa_messages
*
ERROR at line 1:
ORA-01775: looping chain of synonyms
I've looked at the following so questions, but it doesn't seem to be helping. Maybe you can see something I don't:
I get an ORA-01775: looping chain of synonyms error when I use sqlldr
How to debug ORA-01775: looping chain of synonyms?
ORA-01775: looping chain of synonyms but there are no synonyms
Thanks
:UPDATE:
After executing: select * from all_synonyms where synonym_name = 'BNS_SAA_MESSAGES'; as per Craig's suggestion I get:
OWNER SYNONYM_NAME
------------------------------ ------------------------------
TABLE_OWNER TABLE_NAME
------------------------------ ------------------------------
DB_LINK
--------------------------------------------------------------------------------
PUBLIC BNS_SAA_MESSAGES
ORDMSO BNS_SAA_MESSAGES
:UPDATE: 2
Running: select * from all_tables where table_name = 'BNS_SAA_MESSAGES';
SQL> select * from all_tables where table_name = 'BNS_SAA_MESSAGES';
no rows selected
I would run this to see where the synonym is actually pointing:
select *
from all_synonyms
where synonym_name = 'BNS_SAA_MESSAGES'
I am guessing the synonym is pointing to the wrong TABLE_OWNER.
UPDATE
So where is the table actually at? You can find this using:
select *
from all_tables
where table_name = 'BNS_SAA_MESSAGES'
If table_owner is not 'ORDMSO', then you need to either update the synonym to point to the correct location or run the Create table... script as ORDMSO.
UPDATE2
Can you run the Create table... script as ORDMSO? If not, you are going to need to have someone with higher privileges run:
select *
from dba_tables
where table_name = 'BNS_SAA_MESSAGES'
to figure out where the table really is, and then update the synonym accordingly.
It looks like the output is from running this a second time, which you hinted at; the ORA-00955 from the create public synonym shows that has been done before somewhere (as does the all_synonyms query you ran), and it clearly exists from the other errors. You wouldn't have got exactly these errors the first time you ran it, but would on every subsequent run.
At a mimimum the first code snippet should drop the public synonym before dropping the table, if you want it to be rerunnable.
But the first snippet doesn't seem to be run at all. There are no success or failure messages from Oracle. The only real clue to why is this:
Processing bns_saa_messages
cat: cannot open bns_saa_messages.sql
Which is a shell script problem, not really an Oracle one. Without seeing the shell script it's rather hard to tell quite what's wrong, but I suspect the script is building a temporary .sql file from various sources and then running it through SQL*Plus; but the vital bns_saa_messages.sql file is missing. Presumably that's where the first snippet is supposed to be; and since that seems to exist, this could beas simple as a name mismatch between the file and what the script is expecting, or the script is doing a cd and the file is in the wrong directory, or something equally trivial. But maybe not... not enough info.
Are you generating an export?
My solution with a BD oracle 11g was:
See the SYS_EXPORT objects, use Oracle SQL Developer, connect to the DB and execute the following:
Select owner, object_name, object_type, status from dba_objects where object_name like '%SYS_EXPORT%'
Objects SYS_EXPORT
Then with the user: sqlplus / as sysdba removes the created objects.
Delete objects SYS_EXPORT
SQL>drop public synonym sys_export_full_01;
SQL>drop public synonym sys_export_full_02;
SQL>drop public synonym sys_export_full_03;
SQL>drop public synonym sys_export_full_04;
After this you can generate the export.
Related
i need to use synonym as variable in a block. I have 2 different schemas with same tables on them and job that switches between schemas making one active. Now I want to write a block checking which schema is active with ALL_SYNONYMS and using result as part of a query.
Here is example:
DECLARE
OWNER VARCHAR2(15);
BEGIN
SELECT TABLE_OWNER
INTO OWNER
FROM ALL_SYNONYMS
WHERE TABLE_NAME = 'MY_TABLE1';
SELECT *
FROM OWNER.MY_TABLE2 ;
END;
But I’m getting ORA-06550 table or view does not exist, and when i run query itself where i put value from ALL_SYNONYMS it returns result.
Any idea how to fix this?
Thanks
You are attempting using symptoms incorrectly. Synonyms are used so you do not need to know which is active. According to the documentation:
Synonyms provide both data independence and location transparency.
Synonyms permit applications to function without modification
regardless of which user owns the table or view and regardless of
which database holds the table or view.
You just use the synonym instead of the object itself.
create table evens( id integer generated always as identity
, val integer
) ;
create table odds( id integer generated always as identity
, val integer
) ;
insert all
when mod(val,2) = 0 then into evens(val)
when mod(val,2) = 1 then into odds(val)
select level val
from dual connect by level <= 10;
-- create the synonym then use it in Select;
create or replace synonym current_even_odd for evens;
select * from current_even_odd;
-- now change the synonym, then run the EXACT same query.
create or replace synonym current_even_odd for odds;
select * from current_even_odd;
In this case it is not quite without modification, you need to change the synonym, But it seems you are trying that already.
Note: You cannot create a synonym for a schema but must point it to a specific object.
I attempted a db<>fiddle for the above, but it appears it is having problems at the moment.
I agree with Belayer that the synonym should provide a layer of abstraction on your tables and your procedure shouldn't need to know what the schema is. But the "table or view does not exist" error is likely an issue related to privileges and definer's rights versus invoker's rights.
To directly reference an object in a procedure, the procedure's schema must have a direct grant to the table. However, an ad hoc query only needs a role with privileges on the object. This is why the SQL will work in your IDE but not in the procedure. Ensure the code that modifies objects and switches synonyms is granting privileges to both roles and directly to schemas.
If direct grants are not possible, you will need to modify the procedure to use AUTHID CURRENT_USER and change the SQL statements to use dynamic SQL - which can be a huge pain. For example:
create or replace procedure test_procedure authid current_user is
v_count number;
begin
execute immediate
q'[
select count(*)
from some_table
]'
into v_count;
end test_procedure;
/
If you really do need to manually switch between schemas, then you may want to consider using something like execute immediate 'alter session set current_schema=schema1'; in the procedure and using dynamic SQL for all of the querying.
As system user, I created a new user and grant him dba privileges : GRANT dba TO user_bdda_adminProjet
I'm trying to look into the DBA_ROLE_PRIVS table into a trigger (I didn't paste all my code, feel free to tell me if it's necessary) :
CREATE OR REPLACE TRIGGER my_trigger
INSTEAD OF
INSERT ON vueEnquete
FOR EACH ROW
DECLARE
tmp int;
BEGIN
SELECT COUNT(*) INTO tmp FROM DBA_ROLE_PRIVS;
...
...
END;
/
But when I try to execute this script, I got the following errors :
Erreur(6,3): PL/SQL: SQL Statement ignored
Erreur(6,39): PL/SQL: ORA-00942: table or view does not exist
Looking at different forums, I found that the problem is in general that the user don't have rights to the table.
But when I execute, as my user user_bdda_adminProjet the following line alone (out of a trigger), it works perfectly
SELECT COUNT(*) FROM DBA_ROLE_PRIVS;
Moreover, if I just comment the line in my trigger, it executes without any errors, so I guess the error is specifically at this line.
Thanks in advance for your help and feel free to tell me if you need any further info.
dba is a role, not a privilege.
Privileges obtained through a role are not "active" in PL/SQL. You need to grant the select privilege on the DBA_ROLE_PRIVS directly to the user.
I've got a synonym on a remote Oracle database that I can access in SQL over a database link, eg,
insert into my_table select * from my_synonym#my_database_link;
If I put the above statement into a PLSQL block, it won't compile, giving the error message "ORA-00980: synonym translation is no longer valid". The standard explanation is the table that the synonym points to has been dropped, etc, but this is not the case because the statement works in SQL.
If something works in SQL but not in PL/SQL then in most cases this is a problem with privileges.
Any privilege that a user received through a role is not active when you enter a PL/SQL block. So most probably the SELECT privilege on the underlying table was granted through a role and thus is not "active" in the PL/SQL block.
The usual cure for this is to grant the privileges directly to the user, not through a role.
Thank you to everyone who tried to help. This turned out to be an Oracle limitation:
https://support.oracle.com/rs?type=doc&id=453754.1
APPLIES TO:
PL/SQL - Version 9.2.0.8 and later Information in this document
applies to any platform.
Checked for relevance on 01-Apr-2015
SYMPTOMS
A PL/SQL block fails with error: ORA-00980: synonym translation is no
longer valid, when selecting data from a remote database. The
following code demonstrates this issue:
On DB3 (create the table)
CONNECT u3/u3 DROP TABLE tab; CREATE TABLE tab(c1 number); INSERT
INTO tab VALUES (1); COMMIT;
On DB2 (create a synonym to the table on DB3)
CONNECT u2/u2 DROP DATABASE LINK dblink2; CREATE DATABASE LINK
dblink2 CONNECT TO u3 IDENTIFIED BY u3 USING 'EMT102U6'; SELECT *
FROM global_name#dblink2; DROP SYNONYM syn2; CREATE SYNONYM syn2
FOR tab#dblink2; SELECT * FROM syn2;
On DB1 (create a synonym to the synonym on DB2)
CONNECT u1/u1 DROP DATABASE LINK dblink1; CREATE DATABASE LINK
dblink1 CONNECT TO u2 IDENTIFIED BY u2 USING 'EMT102W6'; SELECT *
FROM global_name#dblink1; DROP SYNONYM syn1; CREATE SYNONYM syn1
FOR syn2#dblink1; SELECT c1 from syn1;
This works in SQL but fails when called from PL/SQL
DECLARE num NUMBER; BEGIN SELECT c1 INTO num FROM syn1; END;
/
ERROR at line 4: ORA-06550: line 4, column 3: PL/SQL: ORA-00980:
synonym translation is no longer valid ORA-06550: line 4, column 3:
PL/SQL: SQL Statement ignored
CAUSE
This issue was reported in Bug 2829591 QUERING FROM A PL/SQL
PROCEDURE IN 9I -> 8I-> 7.3.4, GETTING ORA-980. This bug was closed
as 'NOT A BUG' for the following reasons
PL/SQL cannot instruct middle database (DB2) to follow the database
link during the compilation phase. Therefore in order for this PL/SQL
block to compile and run, both database links dblink1 and dblink2
should be defined on the front end database - DB1. During runtime
database link dblink2 will be looked up in DB2 as expected.
SOLUTION
To implement the solution, please execute the following steps:
Create a database link dblink2 on DB1 pointing to DB3
SQL> create database link dblink2 connect to u3 identified by u3 using
'EMT102U6';
Create and compile the PL/SQL block on DB1.
CREATE DATABASE LINK dblink2 CONNECT TO u3 IDENTIFIED BY u3 USING
'EMT102U6';
SELECT * FROM global_name#dblink2; DECLARE num NUMBER; BEGIN
SELECT c1 INTO num FROM syn1; END; / PL/SQL procedure successfully
completed.
TIP: Another option is to use dyanmic SQL in the PL/SQL block as a
work around. When using dynamic SQL the database link is not resolved
at compile time but at runtime.
Workaround solution is to use an Oracle view instead.
CREATE VIEW v_my_synomym as (select * from my_synonym#my_database_link);
Then reference the view in your package or procedure i.e.:
insert into my_table select * from v_my_synonym;
Check in remote database grants for "my_synonym" must be almost "select" for the user you use in connect string, check also the object which this synonym points at (maybe someone deleted the table).
I found this issue when owner of the table/view/procedure are not match with owner mentioned in SYNONYM.
Example : If owner of table TABLE_BRACH is ownerA and in Synonym mentioned table owner is something else (Not ownerA).
Solution:
1. Drop the SYNONYM
2. Create that with same name with correct owner.
CREATE PUBLIC SYNONYM BRANCH FOR ownerA.TABLE_BRACH ;
Using SQLDeveloper 4.0.1.14 to create an export script (separate files & "drops" checked), it generated me those 4 lines among others in DROP.sql:
DROP SYNONYM "PUBLIC"."DUAL";
DROP SYNONYM "PUBLIC"."DBMS_SQL";
DROP SYNONYM "PUBLIC"."DBMS_LOCK";
DROP SYNONYM "PUBLIC"."DBMS_OUTPUT";
Now that I have accidentally passed the whole script using SYSTEM user, I can no longer do modification (create or drop tables) to the database, I have that error popping:
An error was encountered performing the requested operation:
ORA-00604: error occurred at recursive SQL level 1
ORA-00942: table or view does not exist
00604. 00000 - "error occurred at recursive SQL level %s"
*Cause: An error occurred while processing a recursive SQL statement
(a statement applying to internal dictionary tables).
*Action: If the situation described in the next error on the stack
can be corrected, do so; otherwise contact Oracle Support.
Vendor code 604
The problem is that I'm getting that error event when I try this:
CREATE OR REPLACE PUBLIC SYNONYM "DUAL" FOR "SYS"."DUAL";
I precise that the SYS.DUAL table still exists as SELECT 1 FROM SYS.DUAL works but SELECT 1 FROM DUAL fails with ORA-00942: table or view does not exist.
I tried to recreate the synonym as SYSTEM and SYSDBA with the same failure.
Can I recreate those synonyms with another way?
Try it as SYS but without the doauble quotes, i.e.:
CREATE OR REPLACE PUBLIC SYNONYM DUAL FOR SYS.DUAL;
not
CREATE OR REPLACE PUBLIC SYNONYM "DUAL" FOR "SYS"."DUAL";
As I understand it the double quotes make the object name case sensitive.
Update - If you have access to metalink then you will find the answer in note 973260.1, something aboput a trigger firing :
ALTER SYSTEM SET "_SYSTEM_TRIG_ENABLED"=FALSE SCOPE=MEMORY;
CREATE OR REPLACE PUBLIC SYNONYM DUAL FOR SYS.DUAL;
ALTER SYSTEM SET "_SYSTEM_TRIG_ENABLED"=true SCOPE=MEMORY;
The note suggest that if this doesnt work, query DBA_TRIGGERS to find a BEFORE CREATE trigger enabled, and if found disable it and then re-issue create synonym statement, then re-enable the trigger.
I've created a package that contains a stored procedure that I plan to invoke from a separate application. The stored procedure will return a sorted list of all the views and tables in the schema. To do that, it performs a simple select on the DBA_TABLES and DBA_VIEWS synonyms, as shown below:
CREATE OR REPLACE
PACKAGE BODY TITAN_ENTITY AS
PROCEDURE GETSCHEMAOBJECTS (RESULTS IN OUT T_CURSOR)
IS
V_CURSOR T_CURSOR;
BEGIN
OPEN V_CURSOR FOR
SELECT 'T' OBJECTTYPE, TABLE_NAME OBJECTNAME
FROM DBA_TABLES
WHERE OWNER = 'SONAR5'
UNION ALL
SELECT 'V' OBJECTTYPE, VIEW_NAME OBJECTNAME
FROM DBA_VIEWS
WHERE OWNER = 'SONAR5'
ORDER BY OBJECTNAME;
RESULTS := V_CURSOR;
END GETSCHEMAOBJECTS;
END TITAN_ENTITY;
I have verified that the synonyms in question exist, and are public:
CREATE PUBLIC SYNONYM "DBA_TABLES" FOR "SYS"."DBA_TABLES"
CREATE PUBLIC SYNONYM "DBA_VIEWS" FOR "SYS"."DBA_VIEWS"
My understanding is that, because they are public, I don't need any further permissions to get to them. If that understanding is incorrect, I wish someone would disabuse me of the notion and point me to more accurate data.
Now here's my problem: I can open a worksheet in Oracle SQL Developer and select from these tables just fine. I get meaningful data just fine (567 rows, as a matter of fact). But when I try to execute the stored procedure, Oracle complains with a compilation error, as shown below:
Error(9,8): PL/SQL: SQL Statement ignored
Error(10,16): PL/SQL: ORA-00942: table or view does not exist
When I double-click on that second error message, SQL Developer takes me to the first FROM clause ("FROM DBA_TABLES").
So I'm fairly stumped. I know SQL Server pretty well, and I'm new to Oracle, so please bear with me. If you could provide some clues, or point me in the right direction, I'd really appreciate it.
Thanks in advance!
Use ALL_TABLES and ALL_VIEWS instead of DBA_TABLES and DBA_VIEWS. ALL_% views should be accessible to all users.
If you select from a table or a view in a stored PL/SQL-procedure or a stored PL/SQL-function you need a direct grant. A grant via a database role isn't enough.
You probably need a direct grant on view dba_tables. (public) synonyms are just (public) synonyms. You need directly granted select rights.
See here: http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:48704116042682#48798240264807
Edit: Sorry, I glossed over the part where you seem to say that you can select from DBA_TABLES directly. Most likely the issue is that your privileges are granted through a role as someone else answered. But it's still worth explaining that your understanding of PUBLIC synonyms is incomplete, and that using ALL_TABLES would be better if it accomplishes what you need.
The synonym being PUBLIC only means that all users can reference the synonym; it does not grant them any access to the object that the synonym refers to.
What you would do to most directly solve this error is grant SELECT privilege on the SYS views to the user(s) that will run this procedure. However, I think that is a very bad idea.
As suggested by Raimonds, consider whether you can get what you need from USER_TABLES or ALL_TABLES instead. What user is calling this procedure, and what access does that user have to SONAR5's tables?
Generally, if your application is interested in a table, presumably it has some privileges on it, in which case is should be listed in ALL_TABLES.