I experienced an ORA-00942 ("table or view does not exist") when executing
select * from brunch
However, no such problem when executing
select * from joe.brunch
May i know what is the issue here?
Unqualified, BRUNCH refers to a different object than JOE.BRUNCH in your current session. You've got a couple of options to fix that.
Create a public synonym. This will allow any user that has privileges on the JOE.BRUNCH table to access it by querying BRUNCH
CREATE PUBLIC SYNONYM brunch
FOR joe.brunch
Create a private synonym. This will allow just the current user to access the JOE.BRUNCH table by querying BRUNCH
CREATE SYNONYM brunch
FOR joe.brunch
Change the current schema for the current session to JOE. This will cause all unqualified references in the current session to resolve to the JOE schema rather than to the current user's schema
ALTER SESSION SET current_schema = JOE
There are several possible causes
1) there is more than one object (table,view, procedure, etc) called brunch. Oracle does not know which one you are referring to.
2) most likely cause: the table exists in the joe schema but you are connecting as another user who has not been granted select on the joe.brunch object
Try
Grant select on joe.brunch to your_user
and try this and see how many objects match the name brunch
select *
from all_objects
where object_type in (‘TABLE’,'VIEW’)
and object_name = ‘brunch‘;
I found that the table I was referencing (Flyway's schema_version table), was created with double quotes... and thus needed double quotes wherever it was referenced.
Here's what Oracle says:
A quoted identifier begins and ends with double quotation marks (").
If you name a schema object using a quoted identifier, then you must
use the double quotation marks whenever you refer to that object.
In practice, these worked:
SELECT * FROM MYSCHEMA."schema_version";
SELECT * FROM "MYSCHEMA"."schema_version";
When this didn't (-> ORA-00942: table or view does not exist):
SELECT * FROM MYSCHEMA.schema_version;
Related
I have to do CRUD operations on a table that is not owned by the user I am using to connect to my Informix database. I have been granted the necessary privileges to do the operations, but I do not know how to do the actual query.
I have little experience with Informix, but I remember in OracleDB I had to do reference the shema like so:
SELECT * FROM SCHEMA.TABLE;
In Informix should I reference the user that owns the table ? Like :
SELECT * FROM OWNER:TABLE
Or can I just do :
SELECT * FROM TABLE
Thanks for any help !
In Informix you can generally use the table name without or without the owner prefix unless the database was created with mode ANSI in which case the owner prefix is required. Note that the correct syntax when using the owner is to use a period "." as in:
SELECT * FROM owner.table;
The colon is used to separate the database name as shown in the Informix Guide to SQL: Syntax https://www.ibm.com/docs/en/informix-servers/14.10?topic=segments-database-object-name#ids_sqs_1649
FYI you can determine if the database is mode ANSI with this query:
SELECT is_ansi FROM sysmaster:sysdatabases WHERE name = "<database name>";
There are some changes on the core product on which I'm working and some tables become now views and they are not working anymore because a view cannot be referenced with the schema name in front.
For example, the below will return an error: ORA-00942: table or view does not exist
select * from my_schema.my_view;
while a direct select from the view works fine
select * from my_view;
In case of a table, both scenarios above are working fine, is just the view that doesn't accept schema_name in front.
Why is that? Are there any decent workarounds?
EDIT: the selects are executed with my_schema user
Thanks all for your help, especially #mathguy.
Basically the problem was that my_view was in fact a public synonym for my_view_r which was the actual view and being public, you cannot call it using the schema name in front like I was trying. eg:
select * from my_schema.my_view;
Maybe it will be helpful for others that are facing this issue in the future, the workaround would be to create a private synonym to the same view (my_view_r) using the schema name like below:
create synonym my_schema.my_view for my_view_r;
This is the only way to call a synonym using the schema name.
It's a grant issue.
grant all on my_view to my_schema
Make sure your schema really is the owner by running:
Select * from all_objects where object_name = 'my_view';
I have a view stvytro with owner baninst1. There is a public synonym of the same name. The following both work:
select * from STVYTRO;
select * from baninst1.stvytro;
Can any one see what's wrong with this:
User ABC:
create table def.something (
id number,
ref number references def.anotherTable(id)
);
create role ROUser;
grant select on def.something to ROUser;
grant ROUser to ghi;
User DEF:
select * from something;
...
X rows returned
User GHI:
select * from def.something;
ORA-00942: table or view does not exist
Is the fact that there's a foreign key, that GHI doesn't have access to, on def.something the problem?
EDIT I've just tried this again on another server and it works fine (i.e., as expected). Not entirely sure what's going on here, but I think it may have something to do with some error on my part... As such, I'm voting to close the question.
You are most probably running that SELECT statement in PL/SQL block? In PL/SQL, priviliges granted through roles are not recognized. Try adding direct SELECT privilege on that table and see if it works.
I am using MyBatis 3 to create a request (seen below) however, I am getting:
ORA-00942: table or view does not exist
where SYNONYM_A is a public Synonym for a table in another database...
I know the example doesn't really help, but the real question is, "Is there a special syntax for synonyms in Batis?" Has anyone done this, or failed, and can tell me, so I don't spend a great deal of effort, if it is not valid in Batis?
#Select("select * from SYNONYM_A where some_det_key in (SELECT DATA_KEY FROM SOME_PARENT_TABLE WHERE PARENT_KEY = 1234 AND (ATTACH_PARENT_FLG = 1 or ATTACH_PARENT_FLG is null) AND DATA_SRC = 'LV_SOME_DET') ORDER BY pair
Provide the select grant FROM the PARENT schema to the current schema once again for the table of which SYNONYM_A is a synonym of.
And is SYNONYM_A a synonym for a Table or a synonym of another SYNONYM in the PARENT schema?
In case it is, u need to provide grant from the ultimate base schema where the actual table is located once again 'WITH GRANT OPTION'
A public synonym does not mean that grants are not required from the schema in which the parent table lies(if the synonym and the table lies in two different schemas, that is). You need to clarify your concept of public synonyms :) .
But thats not the point here.
just do:
SELECT * SOME_TABLE"#"CONNECTION_TO_ANOTHER_DATABASE;
If this gives you ORA-XXXX: Table or view doesnot exist, then this is the cause.
There are two possibilities:
1.CONNECTION_TO_ANOTHER_DATABASE has got corrupted/doesnot exist.
You can check this by doing queries like :
Select sysdate from duals#CONNECTION_TO_ANOTHER_DATABASE;
Select * from user_objects#CONNECTION_TO_ANOTHER_DATABASE;
If this too gives you the same error then that's it, your CONNECTION_TO_ANOTHER_DATABASE is gone.
If this does not give any error and gives some valid o/p then:
2.Probably the "SOME_TABLE" at the remote database does not exist!
The answer is....
I was connected to the wrong database instance!! I had built extended AbstractRoutingDataSource, and was pulling the server name for the datasource from a primary database. I discovered that another individual had populated this table incorrectly, and pointed me to a database where the synonym did not exist.
Thank you for your responses, and your time.
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.