What happens to an existing DB2 view, if the table is dropped? - view

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.

Related

Oracle : table always "exist" after drop table

I'm using Oracle and I have a strange thing.
I dropped a table using :
drop table t_my_table, and committed.
But when I launch select * from t_my_table, it shows the data, as if the table is not dropped.
I tried disconnecting and reconnecting, it stills shows the data when I select.
And when I once again try with :
drop table t_my_table, it tells me that this table does not exist.
But if I run select again, the data is always there.
How is this possible ?
Thank you.
You mean this case?
create view t_my_table as
select 'I''m here' as txt from dual;
drop table t_my_table;
ORA-00942: table or view does not exist
But
select * from t_my_table;
TXT
--------
I'm here
solution of the most probably cause
select OBJECT_TYPE from user_objects where object_name = 'T_MY_TABLE';
OBJECT_TYPE
-------------------
VIEW
You defined a view (or other object type other than TABLE), that can't be dropped with DROP TABLE, but can be selected.
Simple check in USER_OBJECTS the OBJECT_TYPE. You may alternatively see also SYNONYM as proposed in other answer.
Note that it is not a MATERIALIZED VIEW as if you try to drop a Materialized View with DROP TABLE a different error message is raised:
ORA-12083: must use DROP MATERIALIZED VIEW to drop T_MY_TABLE
What does this return?
select * from all_synonyms
where synonym_name = 'T_MY_TABLE';
I suspect there is a synonym T_MY_TABLE that points to a table in a different schema.
drop table t_my_table purge;
Specify PURGE if you want to drop the table and release the space associated with it in a single step. If you specify PURGE, then the database does not place the table and its dependent objects into the recycle bin.
...
Using this clause is equivalent to first dropping the table and then purging it from the recycle bin. This clause lets you save one step in the process. It also provides enhanced security if you want to prevent sensitive material from appearing in the recycle bin.
Probably something different is happening.
Normal case would be:
SQL> create table t1 as select 1 a from dual;
Table T1 created.
SQL> drop table t1;
Table T1 dropped.
SQL> select * from t1;
Error starting at line : 22 in command -
select * from t1
Error at Command Line : 22 Column : 20
Error report -
SQL Error: ORA-00942: table or view does not exist
00942. 00000 - "table or view does not exist"
*Cause:
*Action:
So what was the message after the drop table?
Is t_my_table really a table?
Try select * from all_objects where lower(object_name) = 't_my_table'

SQLDeveloper Trigger Error report - ORA-00942: table or view does not exist

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?

Redefine materialized view with no downtime

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');

Need to update an Oracle view, but the base table doesn't exist

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..

Oracle: Recreate database view after modifying varchar column size

I've made some changes to columns in a database table (increasing the size of varchar), however I need to have the view of the table refreshed to pick up this change. In SQL server 2005 I would use the script to -> alter to recreate the script for the view. I'm trying to figure out what the Oracle SQL command would be to rebuild the view to display the change of the column?
Unless your view is explicitly restricting the size of the column, it will pick up the change automatically. It may have been invalidated by the table change but would be automatically recompiled when first used; or can be manually recompiled with alter view <view name> compile.
If you do so:
create table sample_table(text varchar2(10));
insert into sample_table (text) values('text...');
create view sample_view as select * from sample_table;
select * from sample_view;
alter table sample_table modify text varchar2(200);
You do not do anything to promote this change in view in Oracle database.
Or you can use "ALTER VIEW sample_view COMPILE" (how wrote #AlexPole or #devio). Oracle do this automatically when you firstly use select on sample_view after alter table.
Try
ALTER VIEW MyView COMPILE;

Resources