Oracle table SELECT rights issue - sql

My application has few tables on Oracle where user XYZ is the schema owner. Tables has been created using XYZ. And I would like to have ABCUSER to have CRUD rights on these tables. I have given the access via GRANT ALL ON TABLEABC to ABCUSER and grant is succeeded.
But when this user(ABCUSER) tries to query the DB (select * from TABLEABC) it doesn't seem to work. I get error message
ORA-00942: table or view does not exist
00942. 00000 - "table or view does not exist"
*Cause:
*Action:
Error at Line: 1 Column: 14
Could you please tell what am I missing ?

User ABCUSER has privileges on the table but doesn't own it. So you need to include the schema in the query:
select * from XYZ.TABLEABC
/
If you don't want to hardcode the schema name in your programs your user can build a synonym:
create synonym TABLEABC for XYZ.TABLEABC
/
Then the original query will work for ABCUSER.
Note that ABCUSER will require the CREATE SYNONYM privilege.

As APC says, you are missing a SYNONYM.
You might want either a PRIVATE or PUBLIC synonym depending upon who you want to be able to view the table.
A good description of the various types and their uses is here:
http://www.orafaq.com/wiki/Synonym

Related

table name includes the schema name of another user

I was running a script on the database that grants execute on all tables for the user 'R_USER' to the 'APP_WRITER' user. I received a "table or view does not exist" error.
to debug I put an dbms_output.putline(r.TABLENAME).
I noticed the problem is that there is a table on the R_USER with the name= 'USER_ARCH.LOGS', there is a schema in the database for the USER_ARCH, so there is this ambiguity.
My question is, how do I drop the 'USER_ARH.LOGS' table in the R_USER schema and not the USER_ARCH schema?
As simply using drop table USER_ARH.LOGS will try to drop the wrong table and give me an "insufficient privileges" error.
You need to use a quoted identifier:
DROP TABLE R_USER."USER_ARCH.LOGS";

ORA-00942 error is generating while creating a view

I have created a new view named CONS_INTERRUPTED_DATA for the main user hfdora and the view has been created successfully. But when I am trying to create the same view for another user (cis) of the same database after giving all the privileges to the user (cis) I am getting the below error,
*oms_consumer
ERROR at line 13:
ORA-00942: table or view does not exist
Both the user hfdora and cis are the part of same database and this oms_consumer table is present at the database
I have granted the following privileges for the user cis before creating the view
grant select on energization_info to cis;
grant select on trigger_info to cis;
grant select on oms_source to cis;
grant select on oms_consumer to cis;
grant connect,resource,dba to cis;
My sql query to create the view,
>CREATE OR REPLACE VIEW CONS_INTERRUPTED_DATA AS
SELECT
trigger_info_A.b1 AS FDR_RMU_OFF_B1, trigger_info_A.b2 AS FDR_RMU_OFF_B2,
trigger_info_A.B3TEXT AS FDR_RMU_OFF_B3TEXT, trigger_info_A.elem AS FDR_RMU_OFF_ELEM,
trigger_info_B.b1 AS FDR_RMU_RESTORE_B1, trigger_info_B.b2 AS FDR_RMU_RESTORE_B2,
trigger_info_B.B3TEXT AS FDR_RMU_RESTORE_B3TEXT,
trigger_info_B.elem AS FDR_RMU_RESTORE_ELEM,
oms_consumer.consumer_code, energization_info.b1 AS AFFECTED_B1,
energization_info.b2 AS AFFECTED_B2, energization_info.b3text AS AFFECTED_B3TEXT,
to_char(energization_info.deenergized_date, 'DD-MM-YYYY Hh24:MI:SS') AS DEENERGIZED_DATE,
to_char(energization_info.energized_date, 'DD-MM-YYYY Hh24:MI:SS') AS ENERGIZED_DATE,
trigger_info_A.comments AS KEY
FROM
energization_info,
trigger_info trigger_info_A,
trigger_info trigger_info_B,
oms_consumer
WHERE
(energization_info.trigger_number = trigger_info_A.trigger_number)
AND (energization_info.ENERGIZED_TRIGGER_NUMBER = trigger_info_B.trigger_number)
AND (energization_info.b1 = oms_consumer.B1NAME
AND energization_info.b2 = oms_consumer.B2NAME
AND energization_info.b3 = oms_consumer.B3NAME)
WITH READ ONLY;
The first step in diagnosing a problem when creating a view is to try the select part on its own. In this case you would still get the ORA-00942 error, but the problem is now just a query and access issue and not to do with the view specifically.
When you get ORA-00942: table or view does not exist, it's because either:
The table or view name that you typed really doesn't exist.
Check the spelling - maybe there is a typo.
Are you connected to a database where it exists? Perhaps you are on a test system that doesn't have it.
Query dba_objects to see whether the table exists in another schema. (If you don't have privileges to query dba_objects, all_objects lists everything you have permission to view, which may be some help.)
It really does exist, but it's in another schema.
In that case, there are two possible issues:
You don't have permission to query it. The table's owner needs to grant read on xyz (substitute the actual table name for xyz) to either
you
public (if you want everyone to be able to see the data, not always advisable)
a role that you have (but roles aren't used by stored PL/SQL or views, though, so it's possible that you can query a table in another schema thanks to a role that you have, but still not be able to create a view or a procedure that uses it.)
You need to specify the schema. Say you want to query the REGIONS table in HR but you are connected as SCOTT. If you just select * from regions it will look for SCOTT.REGIONS, which doesn't exist. To fix that, do one of the following:
use hr.regions explicitly in your query.
in your schema, create or replace synonym regions for hr.regions;
Now whenever you refer to regions, the database will automatically redirect to hr.regions.
in any schema with permission to create public synonyms:
create or replace public synonym regions for hr.regions;
Now everyone connecting to the database will have any references to regions redirected to hr.regions, which isn't always a good idea, but it's one option anyway.
alter session set current_schema = hr;
Now the default schema for resolving names of objects is HR and not the one you logged into. For applications that always log in as a different user than the one that owns the tables, you can create an after logon trigger so this is always set. Then they can just refer to regions etc without needing to specify any schema and without any synonyms.
My issue has been resolved. :-)
I have made the following changes,
FROM
hfdora.energization_info,
hfdora.trigger_info trigger_info_A,
hfdora.trigger_info trigger_info_B,
hfdora.oms_consumer
Now the same view is created for the user cis.

SQL Developer: Why can't I select by column synonym?

I just created a column synonym
CREATE PUBLIC SYNONYM col_syn FOR X_CHILD.FIRST_NAME;
This was executed without error.
But when i say
select dob, col_syn from x_child;
I get this:
ORA-00904: "COL_SYN": invalid identifier
00904. 00000 - "%s: invalid identifier"
*Cause:
*Action:
Error at Line: 4 Column: 13
The column "first_name" for sure exists:
select * FROM x_child;
shows:
I've pressed commit at least 18 times and restarted SQL developer. This did not help.
Also, when I click on synonyms in this schema, there's nothing there. And the only synonym i can see is the table synonym. Am I supposed to be able to see the column synonym here too?
A synonym, which is an alternative name for a table, view, sequence, procedure, stored function, package, materialized view, Java class schema object, user-defined object type, or another synonym. You cannot have a synonym to a column
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. However, synonyms are not a substitute for privileges on database objects. Appropriate privileges must be granted to a user before the user can use the synonym.
When you create the synonym in your example, the reference object does not need to exist at all. In your case
CREATE PUBLIC SYNONYM col_syn FOR X_CHILD.FIRST_NAME;
you are creating a public synonym ( available for everybody ) which makes a reference to the object X_CHILD ( that is why you have in your dba_synonyms as reference_name X_CHILD ) and as reference_type TABLE ( not column )
Specify the schema to contain the synonym. If you omit schema, then Oracle Database creates the synonym in your own schema. You cannot specify a schema for the synonym if you have specified PUBLIC.
https://docs.oracle.com/en/database/oracle/oracle-database/18/sqlrf/CREATE-SYNONYM.html#GUID-A806C82F-1171-478E-A910-F9C6C42739B2

How to grant "select" permission on public synonym "SHC.ABC" of table "SHC.ABC"

I created table called "SCH.ABC" and created PUBLIC synonym "SCH.ABC" now I want to Grant "select" permission to schema "SCH1" on synonym "ABC" . How can i do that please help resolving this.
I am creating synanym as same name of table, while granting permission we will not specify object type whether it is a table or a synonym.
If given, grant select on ABC to sch1; then which object type will get granted synonym or table ?
You already created a public synonym called abc, and you can grant selecting to a particular schema as
grant select on abc to sch1;
where you do not need to qualify with schema name as sch.abc by connecting to sys or system schemas.
or you can grant to all schemas as
grant select on abc to public;
and you don't need to qualify the public synonym abc with the schema name. Use
select * from abc;
in every schema in the database.
Thank you very much for your interest to answering it. I just now found that, in that case synonym only will get precedence of grant. I tested by drop synonym in my home Schema and tried accessing it in another schema it was giving error and i again created synonym after that it was working fine.

Cannot find table v$parameter in Oracle

I want to get the number of sessions in Oracle using the SQL query:
SELECT value FROM v$parameter WHERE name = 'sessions'
But I get this error:
Error starting at line 1 in command:
SELECT value FROM v$parameter WHERE name = 'sessions'
Error at Command Line:1 Column:18
Error report:
SQL Error: ORA-00942: table or view does not exist
00942. 00000 - "table or view does not exist"
*Cause:
*Action:
Maybe the Oracle user that I use is not privileged?
Generally the better approach is to use a procedure and grant the necessary privileges to this procedure. However if you want use SQL directly, you can grant SELECT_CATALOG_ROLE or SELECT ANY DICTIONARY to the user.
Probably. To grant the rights, you need to use the table name as V_$PARAMETER. It comes from some restriction when granting rights on dynamic views.
If you want to use SQL directly (referring to the second option in the accepted answer)
As of Feb 2023, using Oracle version 19, this works...
Connect as SYSTEM and run
grant SELECT ANY DICTIONARY to <user>;
But SELECT_CATALOG_ROLE didn't work for me...
grant SELECT_CATALOG_ROLE to ...;
There are documented differences between the two here:
http://www.petefinnigan.com/weblog/archives/00001461.htm
This is where the author gives the following info and warning:
Well, SELECT_CATALOG_ROLE allows access to some things Oracle deemed not allowed by SELECT ANY DICTIONARY so we need to be careful of granting this role on these grounds. BUT, the overwhelming issue for me is that SELECT_CATALOG_ROLE gives access to 4539 objects and SELECT ANY DICTIONARY gives access to 6228 objects (both numbers in 18c XE)
I am not sure why Oracle do not publish the full list of exclusions in SELECT ANY DICTIONARY but they do publish all of the main tables. We can easily find out anyway. For me, i want to know what does SELECT ANY DICTIONARY really mean. I want to know what i am actually granting if I give out that privilege; well it means access to 6228 tables and views in 18cXE
Both of these rights should not be used; they are a sledgehammer to crack a peanut. If someone needs access to V$SESSION or V$DATABASE and there is a legitimate reason to have that access then grant access on the individual views not SELECT ANY DICTIONARY or SELECT_CATALOG_ROLE.
using the privileges: - select any table, alter any table when running the grant as SYS with SYSDBA in Oracle 12c solved the issue for me.