I'm trying to make an extremely minor change to a view on an oracle database, but what's confusing me is that the base table/view for the view I want to change doesn't seem to exist.
First I did this:
select text from all_views where view_name='(view name)';
and got the view text, which of course was something like this:
SELECT
(fields)
FROM (table)
Trying to run this query on its own returns an error saying that this table or view does not exist. Searching through the lists of table names and views on the all_ tables returns nothing. Creating a new view with the same source select statement tells me I can't make it because the table or view doesn't exist. Now, this is a production database, so this should work because I can use the existing view just fine. I don't have much experience with oracle databases, so I'm probably missing something here.
I'm betting the view is in another schema. Does this return the same as your first query:
select text from all_views where view_name='(view name)' and owner = user;
If that returns no rows, then you need to find the view's owner:
select owner from all_views where view_name = '(view_name)';
And change your SQL to
select (fields) from (view_owner).(table);
You can create a view even if there doesn't exist base table by "FORCE" option("NO FORCE" is
the default) by this way:
CREATE FORCE VIEW test_view AS
SELECT c1, c2 FROM test_table; -- table, which does not exist yet.
Since we did not use the FORCE option, the view was not created.However, trying to access the
view gives an error, because the table TEST_TABLE does not exist yet.
Wow, nevermind. They weren't even asking me to do this. I missed that part in the original email.
By using "FORCE" we can also create a view by dual table(default table for oracle).
1-Example:create force view v1 as select a,b,c from dual;
Warning:view created with compilation error.
2-Example:create force view v2 as select *from dual;
Answer:view created.
Your should use force keyword..
create force view my_view as elect column1 from table_test -- table is not exists here..
Related
We are doing a project on Oracle Apex for university. We have 12 tables and try to build an app for our project. When we try to add a new page for some of our tables (not all of them) we encounter this error error description.
Can someone know how to solve this issue which is really blocking us right now.
We tried everything to solve it. All of our constraints in our tables work. What we don't understand is why we can create sometimes new pages from some tables but for other it does not work.
To me, that (unfortunately) looks like bug as you don't have any impact on Apex' data dictionary tables.
If you connect as a privileged user and check what's exactly being violated, you'll see something like this.
Which table is that constraint related to? Apparently, none:
SQL> select table_name from dba_constraints where owner = 'APEX_200200' and constraint_name = 'WWV_DICTIONARY_CACHE_OBJ_IDX2';
no rows selected
Any luck with (unique) indexes, then? Yes!
SQL> select table_name from dba_indexes where owner = 'APEX_200200' and index_name = 'WWV_DICTIONARY_CACHE_OBJ_IDX2';
TABLE_NAME
------------------------------
WWV_DICTIONARY_CACHE_OBJ
Which columns are used to enforce uniqueness?
SQL> select column_name from dba_ind_columns where index_name = 'WWV_DICTIONARY_CACHE_OBJ_IDX2';
COLUMN_NAME
--------------------------------------------------------------------------------
SECURITY_GROUP_ID
OBJECT_ID
OBJECT_TYPE
SQL>
That's to get you started; you know which table you used for that page so write some more queries and you'll - hopefully - find some move info.
How to "fix" that error? I hope you won't delete or update anything on Apex' dictionary tables! Maybe you'd rather rename that table (to avoid uniqueness violation) and try to use it, with its new name, while creating the page in your application.
If a workspace contains other object types with the same name as a table, APEX data dictionary cache job, ORACLE_APEX_DICTIONARY_CACHE, fails with ORA-00001: UNIQUE CONSTRAINT (APEX_190200.WWV_DICTIONARY_CACHE_OBJ_IDX1)
Workaround: Remove the duplicate object that is not a table. You can list database objects by selecting from sys.dba_objects.
Oracle APEX 19.2 Known Issues
I'd need to know if a table is used in any view. I already tried to select from VIEWS but the query will give me an error:
ORA-00942: table or view does not exist
I'm not even sure that selecting from views is an oracle thing..
Is there any way?
You can find out what views (and other objects) reference a table with this query:
select name, type from user_dependencies
where referenced_name = 'MYTABLE'
and referenced_type = 'TABLE';
I put this code into SQL Developer's Worksheet:
CREATE TRIGGER T_testDSNa
before INSERT
on testDSNa
referencing new as new
for each ROW
BEGIN
SELECT S_testDSN.nextval INTO :NEW.SYSID FROM dual;
END;
I get this:
Error report -
ORA-00942: table or view does not exist
00942. 00000 - "table or view does not exist"
*Cause:
*Action:
Would anyone know why? This has worked for 3 previous tables until I tried to run the DDL to create a 4th. Alternatively, is there a better way to set up an autoincrementing PK?
The problem was lack of schema. Oracle Definition of a schema :
Collection of database objects, including logical structures such as
tables, views, sequences, stored procedures, synonyms, indexes,
clusters, and database links. A schema has the name of the user who
controls it.
If you want to know the objects accessible without alias. You have to look on [USER_OBJECTS]. Which describes the relational objects owned by the current user :
SELECT
OBJECT_NAME
, OBJECT_TYPE
, LAST_DDL_TIME
FROM USER_OBJECTS;
If you want to know the objects accessible to the current user :
SELECT
OWNER
, OBJECT_NAME
, OBJECT_TYPE
, LAST_DDL_TIME
FROM ALL_OBJECTS;
In your case to see your objects in the list of available tables you need:
SELECT * FROM ALL_OBJECTS WHERE OWNER = 'USER';
You can also alter the session to avoid alias :
ALTER SESSION SET current_schema = User;
For priviliges/ roles views you can look at :
SELECT * FROM USER_SYS_PRIVS;
SELECT * FROM USER_ROLE_PRIVS;
The last method but not the most secure to avoid alias. Is to log on with a user that has the same name as the schema.
Hoping that it can help
I was getting the same issue.
Solution: What I observed that my table which I created was surrounded by double quotes, which made it case sensitive.
So for each time I refer to my table, I need to surround it by double quotes.
CREATE TRIGGER T_testDSNa
before INSERT
on "testDSNa"
referencing new as new
for each ROW
BEGIN
SELECT S_testDSN.nextval INTO :NEW.SYSID FROM dual;
END;
refer this link: What exactly do quotation marks around the table name do?
I have a materialized view that I need to redefine the SQL for. We have an external system that hits the view over a db link, and the monster view takes 5 minutes to refresh the data in the view. The only way I know how to redefine the SQL for a view is to drop it and recreate it, but it would be very bad if the external system couldn't find the table, or it didn't have a complete data set. I need to have as little downtime as possible.
Is there any way to do this natively or more elegantly than:
Create public synonym for materialized view and make everything that uses the view use the synonym instead.
Create new materialized view with new SQL
Change the synonym to point to the new view
Drop the old view.
I've got code to do this dynamically but it is getting really ugly. It seems like there should be a better way to handle this.
Oracle has a build in solution for that. Keep in mind that the mview declaration is separate from that of the table.
The original mview
create materialized view mv1 as select dept , count(*) as cnt from scott.emp;
we want to change the declaration so that only dept over 5 will be calculated
drop materialized view mv1 preserve table;
notice the PRESERVE TABLE clause - the table mv1 is not droped - only the mview layer.
desc mv1
now we create the mview with a different query on top of the existing table
create materialized view mv1 on prebuilt table as
select dept , count(*) as cnt from scott.emp where dept > 5;
notice the on prebuilt table clause. the mview is using the existing object.
exec dbms_mview.refresh_mview('mv1');
If we have created a view on an existing DB2 table and then drop the table. What will happen to the view ?
The view becomes invalid/inoperative. Attempts to select from it will fail.
To try it:
create table TEST_TABLE (
TEST_COL INTEGER
);
INSERT INTO TEST_TABLE VALUES(1);
SELECT * FROM TEST_TABLE;
create view TEST_VIEW AS
SELECT * FROM TEST_TABLE;
SELECT * FROM TEST_VIEW;
DROP TABLE TEST_TABLE;
SELECT * FROM TEST_VIEW;
The last statement gives the error:
[IBM][CLI Driver][DB2/NT] SQL0575N View or materialized query table
"TEST_VIEW" cannot be used because it has been marked inoperative.
SQLSTATE=51024
When a view is invalidated, as shown in the above example, DB2 will allow you to recreate that view without dropping it first. This makes it possible to re-run your view DDL files (or simply dump the TEXT column of SYSCAT.VIEWS and execute that).
Nothing happened. Just don't use that view. You can recreate the table again to use the view again later.
It becomes inoperative.
Same information can be found using following query:
SELECT viewscheama,viewname,valid FROM syscat.views
.
For the perticular view , if the "Valid" column has any value apart of 'Y' , then the view will be inoperative.