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.
Related
I have two schema "OWNER" and "USER".
I've created job in "OWNER" schema in PROD and we don't have access to login into this schema. Now I want to find a way to access these jobs in "USER" schema.
Below are the methods, I tried and did not work for me:
1)I created view in "OWNER" schema (create view test_view as select * from all_scheduler_jobs) and gave a grant "GRANT SELECT OWNER.test_view to USER". But still I did not find any records in USER schema.
2)Created a view as mentioned above and after that I created synonym in USER schema( create synonym USER.test_view for OWNER.test_view.
Please let me know if there is anything that I'm missing or is there any other way that I can implement.
The ALL_SCHEDULER_JOBS view only lets you see jobs to which you already have access - essentially just your own. To see properties or output from scheduler jobs belonging to other schemas, USER must have the SELECT ANY DICTIONARY privilege, which would allow access to the DBA_SCHEDULER_JOBS view. Check with your DBA to see if you are allowed to have that privilege (it opens up access to a lot of other things, too), or if they would prefer that you have a custom role that just grants access to the various DBA_SCHEDULER_% views. Note that these views would expose all jobs for all users, not just your OWNER schema; there isn't really a way to fine-tune that.
If USER needs to execute the job in another schema, then it will need the EXECUTE ANY JOB privilege, which would allow it to run any job in any schema. There's no way to make that more fine-grained at this time, either.
You can try below SQL.
SCHEMA: OWNER
commit;
SCHEMA: USER
select * from OWNER.test_view;
I am using postgres and have a new read-only user that has read permissions on all tables in a base schema. I was trying to SELECT some data from a particular view from base schema and was able to see the values from the view. To test the data count I had to make some changes in the view definition and in Postgres there isnt a way to alter the View so I had to drop and recreate the view with new definition using a older user with higher privilege. Now I run the same SELECT query on the View and am getting a permissions error.
ERROR: permission denied for view
SQL state: 42501
I tried Grant SELECT on ALL TABLES on Schema base to user again and was able to see the values from the view. What I dont get is that I havent changed any syntax since the first GRANT, why am I having to run the GRANT SELECT statement again for the new user to be able to access the view ? shouldnt the user already be able to access all the tables and views by default
You can use CREATE OR REPLACE VIEW to change a view definition if you don't change its columns.
In PostgreSQL, permissions are stored on the object. If you drop an object, all its permissions are gone. If you later create an object with the same name, that is still a different object and will have the default permissions.
You can use ALTER DEFAULT PRIVILEGES to grant permissions for objects that are created in the future.
I had a schema in one oracle DB as ui_prod. I asked my DBA team guys to create exactly same schema like ui_prod but as read only and name it ui_prod_readonly. Usually I will use Oracle SQL developer to connect a DB and query directly with table name like below.
--Connect to ui_prod
select * from table
but why I requested to put owner name infront when query for readonly schema they created for me, as without putting it, I get error table not exist.
--Connect to ui_prod_readonly
select * from ui_prod.table
I have project files which hardcode the sql query with only table names and adding owner name in front will cause many changes and effort. Can anyone explain me on this? or provide me any document/link to read. Thanks
You should look into synonyms, apparently the user you are connecting to the database as is not the owner of the objects. So to view the object you have to prepend the names with the schema name (the owner of the object themselves).
http://www.techonthenet.com/oracle/synonyms.php
CREATE OR REPLACE SYNONYM ui_prod_readonly.synonym_name
FOR ui_prod.object_name
It seems to me that your dbas have not created another set of tables but just granted the existing tables to the user ui_prod_readonly.
When you log in to Oracle, the current schema is the name of the user you used to log in. So if you log in with ui_prod_readonly Oracle checks that schema for the table if you do not qualify it with the owner (=schema).
If you want to change the current schema so that you don't need to fully qualify the tables, you can do that with ALTER SESSION
alter session set current_schema = ui_prod;
Once you have done that, you don't need to fully qualify the table with the owner (=schema).
if you need a user to read the data only
its simple to create new user and grant it only select privilege
you can create user and grant select privilege using
CREATE USER [user] IDENTIFIED BY [your_password];
grant select on table to [user]
Is there a way, to select data only form the own schema, even if there is an public synonym?
something like: Select * from current_schema.Table1
more info:
I got a public synonym on table1 on schema1.
now I have a package(on schema2) that selects table1, I want to select table1 of schema2 not schema1.
My problem is, I dont what the user to change the identifier when he uses the package at his server.
edit
I see my question is not clear, what i wanted to know is is there a placeholder for my current schema?
at the moment i need to do this:
Select * from schema2.Table1
and i want is something Like this :
Select * from MySchema.Table1
or
Select * from this.Table1
or
Select * from current_schema.Table1
does something like this exists in oracle?
The scoping rules are quite clear. When the databse parses a query it looks for objects matching the identifiers in your statement in the following order of precedence:
objects of that name in your schema
private synonyms of that name (in your schema)
public synonys of that name
But if you want to be clear certainly you can prefix your table references with the specific schema name. That is helpful in communicating your intent to others looking at your code.
Furthermore, if you have a table TABLE1 in your schema and there is a public synonym called TABLE1 pointing at a table in another schema which you want to query instead you must prefix your reference with that other schema.
"what i wanted to know is is there a placeholder for my current
schema"
No, because it's not necessary. The default is always your current schema. That is, this statement ...
SQL> select * from t23;
... will always select from T23 in your current schema, if it has a table (or a private synonym) with that name.
Note that it is possible to change the value of your current schema, with the ALTER SESSION command:
SQL> alter session set current_schema=scott;
Now if you executed the previous select it would return results from SCOTT.T23 providing the SCOTT schema had such a table, and taht you had privileges on it. You can find out more about Oracle schemas in a blog piece I wrote a while back.
I was trying to understand what problem you were having, and I noticed that your scenario is one user executing a package owned by another user. Now, by default a package owned by SCHEMA2 will run against objects owned by SCHEMA2 and use the privileges on other objects granted to SCHEMA2.
But PL/SQL offers us the ability to change that: the AUTHID clause determines whether the package runs with the definer's privileges (that is the package owner) or invoker's privileges (the current user. So if SCHEMA2 defined their package with AUTHID CURRENT_USER when SCHEMA1 runs it the instance of TABLE2 will be the one in scope of SCHEMA1, which would be the one owned by SCHEMA1 or the one indicated by a public synonym.
Find out more.
An external DB admin guy exported a production database and imported it into test environment. We are using Oracle 9.2. Majority of imported database objects (tables, views, idexes, packages,...) works fine, but we have problems with three specific tables: we can do SELECT,UPDATE, DELETE on those tables, but we can not create views on this tables.
In other words, the folowing works:
create or replace view v_test_view as select 1 x from dual; // we can create views
create or replace view v_test_view as select 1 x from someTable;
select * from problematicTable; // we can select data from problematic table
But this does NOT work:
create or replace view v_test_view as select 1 x from problematicTable;
--> ORA-01031: insufficient privileges
Background info:
db admin used import/export utility to copy the database schema
the version of production and test Oracle are not exactly the same (production is 9.2.0.8, test is 9.2.0.7)
after the initial import was done, the problematicTable was visible in object catalog (and database development tools), but when trying to SELECT from this table, we got back "invalid identifier". After that, the tables were re-imported and now we are able to SELECT from the, but not to create views on them
Any ideas?
UPDATE:
It looks like the situation is even more strange. When using one oracle session we can SELECT data from this table, in another Oracle session (using the same user to login!), we are getting "ORA-00904: invalid identifier"
UPDATE#2:
The export data that was used to import from was sucesfully used to import data to another test environment (lets call it TEST1) which is located on the same instace of Oracle as the problematic one (TEST2). The difference beteween those two environments are that TEST1 uses the same user (schema name) as the production, but TEST2 uses another user (soo the objects were imported into another schema name). The problematicTables do not have any special security properties that are different from the tables that works OK.
Matra
Is the user creating the view granted select on the problematic table via a ROLE? If so, try giving an explicit grant on the table.
From Oracle:
"In order to create a view in a schema, that schema must have the privileges necessary to either select, insert, update, or delete rows from all the tables or views on which the view is based. The view owner must be granted these privileges directly, rather than through a role. The reason is that privileges granted to roles cannot be inherited via objects."
It looks like there was something wrong with the import. So what our DB admin did to fix the problem was:
drop the problematic tables
reimport the structure of the problematic tables (columns, constraints, indexes)
after the structure was re-created he re-imported the data
he also played with the CREATE TABLE AS SELECT to copy the data back and forth
When he was re-creating the table structure he discovered, that the current schema run out of free space (it was not set to auto grow). The strange thing is, that the first import did not complain about insufficient space.
So in theory is that insufficeint space was the reason for corrupted data dictionary.