Let's assume
Table TARGET {
ID IDENTITY ...,
...
JOB_NO NUMBER
}
My question is, how can I generate the JOB_NO (by means of a sequence) so that all inserts that have been committed in a statement have the same job_no.
The output should be something like for the n-th execution of that insert stmt.
ID ... JOB_NO
1 ... 123
2 ... 123
3 ... 123
The following is obviously not working. But what is the correct Oracle syntax?
INSERT INTO TARGET SELECT A.*, B.* FROM my_source_table A, (SELECT x.nextval from dual) B
Thanks a lot
Juergen
You could once select the NEXTVAL for every such insert, which increments the sequence and then use CURRVAL within the INSERT.
Let's say this is your sequence
create sequence seq START WITH 123 ;
Always specify the column names in the INSERT to avoid confusion, don't use select * from
select seq.NEXTVAL FROM DUAL;
INSERT INTO TARGET(JOB_NO,col1,col2,..)
SELECT seq.CURRVAL, a.col1,a.col2 FROM my_source_table A, ..
You should be able to do something like:
insert into target select my_seq.nextval, a.* from source a;
Update based on comment below:
SQL*Plus: Release 12.1.0.2.0 Production on Wed Apr 11 12:48:21 2018
Copyright (c) 1982, 2014, Oracle. All rights reserved.
Connected to:
Oracle Database 12c Standard Edition Release 12.1.0.2.0 - 64bit Production
With the Automatic Storage Management option
SQL> create table a(id number, name varchar2(10));
Table created.
SQL> insert into a values(1,'Larry');
1 row created.
SQL> c/1/2
1* insert into a values(2,'Larry')
SQL> c/Larry/Moe
1* insert into a values(2,'Moe')
SQL> /
1 row created.
SQL> c/2/3
1* insert into a values(3,'Moe')
SQL> c/Moe/Curly
1* insert into a values(3,'Curly')
SQL> /
1 row created.
SQL> commit;
Commit complete.
SQL> select * from a;
ID NAME
---------- ----------
1 Larry
2 Moe
3 Curly
SQL> create table b as select 1 id, a.id id_a, a.name from a where 1=0;
Table created.
SQL> desc b
Name Null? Type
----------------------------------------- -------- ----------------------------
ID NUMBER
ID_A NUMBER
NAME VARCHAR2(10)
SQL> create sequence seq_a;
Sequence created.
SQL> insert into b select seq_a.nextval, a.* from a;
3 rows created.
SQL> select * from b;
ID ID_A NAME
---------- ---------- ----------
1 1 Larry
2 2 Moe
3 3 Curly
Related
I have a table in oracle 11.2.0.3 that I want to capture in the redo logs. The issue is that it has an sdo_geometry field. This is a legacy table that I can not change. But the good news is I do not need that sdo_geometry field.
So I have created a materialized view as shown below.
CREATE MATERIALIZED VIEW LOG ON LEGACY_TABLE_NAME
WITH PRIMARY KEY
INCLUDING NEW VALUES;
CREATE MATERIALIZED VIEW LEGACY_TABLE_NAME_MV
NOLOGGING
NOCACHE
BUILD IMMEDIATE
REFRESH FAST ON COMMIT
WITH PRIMARY KEY
AS
SELECT <List of non sdo_gemoetry columns> FROM LEGACY_TABLE_NAME;
The issue shows up when I do an update and look at the redo logs. Instead of seeing an update statement, I see a delete and insert statements. Since I am using a primary key, I would expect to see the update statement.
Does anyone know what I need to do to ensure that I see an update statement in the redo logs.
Thanks
I think you are misunderstanding what a redolog stores with what a materiliazed view log does.
Let's try to make a test for both scenarios:
LogMiner to verify the content of the redo logfiles, something we can see using v$LOGMNR_CONTENTS.
Example of Materialized view Log and Update operations
Oracle version: 12.2
RedoLog Contents
SQL> create table cpl_rep.test_redo_logs ( c1 number primary key , c2 number ) ;
Table created.
SQL> insert into cpl_rep.test_redo_logs values ( 1 , 1 );
1 row created.
SQL> insert into cpl_rep.test_redo_logs values ( 2 , 2 );
1 row created.
SQL> commit ;
Commit complete.
SQL> update cpl_rep.test_redo_logs set c1=3 , c2=3 where c1 = 2 ;
1 row updated.
SQL> commit ;
Commit complete.
SQL> select * from cpl_rep.test_redo_logs ;
C1 C2
---------- ----------
1 1
3 3
SQL> exit
Disconnected from Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit
Production
$ sqlplus / as sysdba
SQL*Plus: Release 12.2.0.1.0 Production on Sat Aug 8 21:53:05 2020
Copyright (c) 1982, 2016, Oracle. All rights reserved.
Connected to:
Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production
SQL> alter system switch logfile ;
System altered.
SQL> exit
Disconnected from Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit
Production
Now let's start a LogMiner session by loading the redo log files into LogMiner:
SQL> exec dbms_logmnr.add_logfile('/bbdd_odcgrc1r/redo1/redo11.ora' , 1);
SQL> exec dbms_logmnr.add_logfile('/bbdd_odcgrc1r/redo2/redo21.ora' , 1);
SQL> exec dbms_logmnr.add_logfile('/bbdd_odcgrc1r/redo1/redo12.ora' , 1);
SQL> exec dbms_logmnr.add_logfile('/bbdd_odcgrc1r/redo2/redo22.ora' , 1);
SQL> exec dbms_logmnr.add_logfile('/bbdd_odcgrc1r/redo1/redo13.ora' , 1);
SQL> exec dbms_logmnr.add_logfile('/bbdd_odcgrc1r/redo2/redo23.ora' , 1);
PL/SQL procedure successfully completed.
PL/SQL procedure successfully completed.
PL/SQL procedure successfully completed.
PL/SQL procedure successfully completed.
PL/SQL procedure successfully completed.
PL/SQL procedure successfully completed.
SQL> exec dbms_logmnr.start_logmnr(options=>dbms_logmnr.dict_from_online_catalog);
PL/SQL procedure successfully completed.
SQL> select count(*) from v$logmnr_contents where seg_name = upper('test_redo_logs') ;
COUNT(*)
----------
4
SQL> select sql_redo , seg_name from v$logmnr_contents where seg_name = upper('test_redo_logs') ;
SQL_REDO
--------------------------------------------------------------------------------
SEG_NAME
--------------------------------------------------------------------------------
create table cpl_rep.test_redo_logs ( c1 number primary key , c2 number ) ;
TEST_REDO_LOGS
insert into "CPL_REP"."TEST_REDO_LOGS"("C1","C2") values ('1','1');
TEST_REDO_LOGS
insert into "CPL_REP"."TEST_REDO_LOGS"("C1","C2") values ('2','2');
TEST_REDO_LOGS
SQL_REDO
--------------------------------------------------------------------------------
SEG_NAME
--------------------------------------------------------------------------------
update "CPL_REP"."TEST_REDO_LOGS" set "C1" = '3', "C2" = '3' where "C1" = '2' an
d "C2" = '2' and ROWID = 'AAGKh2AAAAAJIH1AAB';
TEST_REDO_LOGS
As you can see above, the UPDATE appears normally as any other DML operation in the SQL_REDO column of V$LOGMNR_CONTENTS. So, obviously the REDO files store any update operation as long as the operation is done in Logging mode, or the database is in FORCE LOGGING MODE, in which case it doesn't matter what mode the operation is done, because it will always be stored.
Materialized View Log
Let's create a materialized view log and a materialized view as you did in your question. However, to verify the content of the MLOG$ tables, I will put the refresh on demand, instead of on commit.
SQL> create table x ( c1 number primary key , c2 number ) ;
Table created.
SQL> insert into x values ( 1 , 1 ) ;
1 row created.
SQL> insert into x values ( 2 , 2 );
1 row created.
SQL> commit ;
Commit complete.
SQL> create materialized view log on x with primary key including new values ;
Materialized view log created.
SQL> create materialized view mv_x nologging nocache build immediate refresh fast on demand with primary key as select c1 , c2 from x ;
Materialized view created.
SQL> select * from x ;
C1 C2
---------- ----------
1 1
2 2
SQL> select * from mv_x ;
C1 C2
---------- ----------
1 1
2 2
SQL> insert into x values ( 3 , 3 );
1 row created.
SQL> commit ;
Commit complete.
SQL> update x set c1=4 , c2=4 where c1=3 ;
1 row updated.
SQL> commit ;
Commit complete.
As we did create the materialized view with refresh on demand, now let's the content of the MLOG$ table
SQL> select * from x ;
C1 C2
---------- ----------
1 1
2 2
4 4
SQL> select * from mv_x ;
C1 C2
---------- ----------
1 1
2 2
SQL> select * from mlog$_x
C1 SNAPTIME$ D O CHANGE_VEC XID$$
---------- --------- - - ---------- ----------------------------
3 01-JAN-00 I N FE 39406677128122001
3 01-JAN-00 D O 00 44473269658586765
4 01-JAN-00 I N FF 44473269658586765
Then I refresh
SQL> select * from x ;
C1 C2
---------- ----------
1 1
2 2
4 4
SQL> select * from mv_x ;
C1 C2
---------- ----------
1 1
2 2
SQL> exec dbms_mview.refresh('MV_X') ;
PL/SQL procedure successfully completed.
SQL> select * from mv_x ;
C1 C2
---------- ----------
1 1
2 2
4 4
SQL> select * from mlog$_x
2 ;
no rows selected
The reason why you don't see UPDATE on DMLTYPE$$ is because you choose Primary Key as WITH clause in your Materialized View creation. In that case, only D or I will appear in the column DMLTYPE$$ , but when it is an update, you will get two rows with the same transaction ID ( XID$$ field in the example above has the same value )
However, check what happen when I use ROWID instead of PRIMARY KEY
SQL> create materialized view log on x with rowid including new values ;
Materialized view log created.
SQL> create materialized view mv_x nologging nocache build immediate refresh fast on demand with rowid as select c1 , c2 from cpl_rep.x ;
Materialized view created.
SQL> select * from cpl_rep.mv_x ;
C1 C2
---------- ----------
1 1
2 2
3 3
SQL> select * from x ;
C1 C2
---------- ----------
1 1
2 2
3 3
SQL> insert into x values ( 4 , 4 ) ;
1 row created.
SQL> commit ;
Commit complete.
SQL> insert into x values ( 5 , 5 );
1 row created.
SQL> commit ;
Commit complete.
SQL> update x set c1=6 , c2=6 where c1=5 ;
1 row updated.
SQL> commit ;
Commit complete.
SQL> select * from x ;
C1 C2
---------- ----------
1 1
2 2
3 3
4 4
6 6
SQL> select * from mv_x ;
C1 C2
---------- ----------
1 1
2 2
3 3
Let' see the content of the M$LOG table now
SQL> col m_row$$ for a18
SQL> select * from mlog$_x ;
M_ROW$$ SNAPTIME$ D O CHANGE_VEC XID$$
------------------ --------- - - ---------- ----------------------------
AAGKh/AAAAAJJWnAAD 01-JAN-00 I N FE 3659458165104006
AAGKh/AAAAAJJWnAAE 01-JAN-00 I N FE 44754731750395757
AAGKh/AAAAAJJWnAAE 01-JAN-00 U U 06 12948119511653544
AAGKh/AAAAAJJWnAAE 01-JAN-00 U N 06 12948119511653544
I have now 4 rows, 2 for the inserts, 1 update for the field C1 and another for the field C2, which are in fact the same transaction ( field XID$$ )
I hope it clarifies how the MLOG$ tables are populated when you choose ROWID or PRIMARY KEYY. Note that materialized view log tables using primary keys also have rupd$_ tables. The rupd$_ table supports updateable materialized views, which are only possible on log tables with primary keys.
There is a master table name as projects master
In another form if I select project-1 sl no need to generate from project master(21819001). after successful 1 record save, if I select same project-1
sl no need to generate like 21819002, for next 21819003, so on.
Again after 3 record save if I select projects-3 sl should generate like 41819001 so on.
I am using Oracle Forms 10g.
Here's an example of what you might do - create additional table which contains the most recent SL_NO for each project. That number is created with an autonomous transaction function which makes sure that in a multi-user environment you won't get duplicates.
PROJECTS_MASTER table and some sample data:
SQL> create table projects_master
2 (project number primary key);
Table created.
SQL> insert into projects_master
2 select 21819001 from dual union all
3 select 41819001 from dual;
2 rows created.
This table will contain the most recent SL_NO for each project
SQL> create table projects_sl_no
2 (project number constraint fk_prsl references projects_master (project),
3 sl_no number);
Table created.
The function itself; if row for PAR_PROJECT exists, it'll update it. Otherwise, it'll create a brand new row in PROJECTS_SL_NO table.
SQL> create or replace function f_proj_sl_no
2 (par_project in projects_master.project%type)
3 return projects_sl_no.sl_no%type
4 is
5 pragma autonomous_transaction;
6 l_sl_no projects_sl_no.sl_no%type;
7 begin
8 select b.sl_no + 1
9 into l_sl_no
10 from projects_sl_no b
11 where b.project = par_project
12 for update of b.sl_no;
13
14 update projects_sl_no b
15 set b.sl_no = l_sl_no
16 where b.project = par_project;
17
18 commit;
19 return (l_sl_no);
20 exception
21 when no_data_found
22 then
23 lock table projects_sl_no in exclusive mode;
24
25 insert into projects_sl_no (project, sl_no)
26 values (par_project, par_project);
27
28 commit;
29 return (par_project);
30 end f_proj_sl_no;
31 /
Function created.
Testing:
SQL> select f_proj_sl_no(21819001) sl_no from dual;
SL_NO
----------
21819001
SQL> select f_proj_sl_no(21819001) sl_no from dual;
SL_NO
----------
21819002
SQL> select f_proj_sl_no(21819001) sl_no from dual;
SL_NO
----------
21819003
SQL> select f_proj_sl_no(41819001) sl_no from dual;
SL_NO
----------
41819001
SQL> select * from projects_sl_no;
PROJECT SL_NO
---------- ----------
21819001 21819003
41819001 41819001
SQL>
As you use Forms, you could call the F_PROJ_SL_NO function in WHEN-VALIDATE-RECORD trigger, PRE-INSERT, or even create a before insert database trigger if you're inserting into a more complex table than the ones I created for testing purposes. Anyway, that should be a simpler part of the story.
The situation is that, when I import a file into the database, one of the first thing I usually do is to assign an unique ID for each record.
I normally do below in TSQL
ALTER TABLE MyTable
ADD ID INT IDENTITY(1,1)
I am wondering if there is something similar in PL SQL?
All my search result come back with multiple steps.
Then I'd like to know what PL SQL programmer typically do to ID records after importing a file. Do they do that?
The main purpose for me to ID these records is to trace it back after manipulation/copying.
Again, I understand there is solution there, my further question is whether PL SQL programmer actually do that, or there is other alternative which making this step not necessary in PL SQL?
OK then, as you're on Oracle 11g, there's no identity column there so - back to multiple steps. Here's an example:
I'm creating a table that simulates your imported table:
SQL> create table tab_import as
2 select ename, job, sal
3 from emp
4 where deptno = 10;
Table created.
Add the ID column:
SQL> alter table tab_import add id number;
Table altered.
Create a sequence which will be used to populate the ID column:
SQL> create sequence seq_imp;
Sequence created.
Update current rows:
SQL> update tab_import set
2 id = seq_imp.nextval;
3 rows updated.
Create a trigger which will take care about future inserts (if any):
SQL> create or replace trigger trg_bi_imp
2 before insert on tab_import
3 for each row
4 begin
5 :new.id := seq_imp.nextval;
6 end;
7 /
Trigger created.
Check what's in the table at the moment:
SQL> select * from tab_import;
ENAME JOB SAL ID
---------- --------- ---------- ----------
CLARK MANAGER 2450 1
KING PRESIDENT 5000 2
MILLER CLERK 1300 3
Let's import some more rows:
SQL> insert into tab_import (ename, job, sal)
2 select ename, job, sal
3 from emp
4 where deptno = 20;
3 rows created.
The trigger had silently populated the ID column:
SQL> select * From tab_import;
ENAME JOB SAL ID
---------- --------- ---------- ----------
CLARK MANAGER 2450 1
KING PRESIDENT 5000 2
MILLER CLERK 1300 3
SMITH CLERK 800 4
JONES MANAGER 2975 5
FORD ANALYST 3000 6
6 rows selected.
SQL>
Shortly: you need to
alter table and add the ID column
create a sequence
create a trigger
The end.
The answer given by #Littlefoot would be my recommendation too - but still I thought I could mention the following variant which will work only if you do not intend to add more rows to the table later.
ALTER TABLE MyTable add id number(38,0);
update MyTable set id = rownum;
commit;
My test:
SQL> create table tst as select * from all_tables;
Table created.
SQL> alter table tst add id number(38,0);
Table altered.
SQL> update tst set id = rownum;
3815 rows updated.
SQL> alter table tst add constraint tstPk primary key (id);
Table altered.
SQL>
SQL> select id from tst where id < 15;
ID
----------
1
2
3
4
5
6
7
8
9
10
11
ID
----------
12
13
14
14 rows selected.
But as mentioned initially,- this only fixes numbering for the rows you have at the time of the update - your'e not going to get new id values for new rows anytime later - if you need that, go for the sequence solution.
You can add an id column to a table with a single statement (Oracle 11g, see dbfiddle):
alter table test_
add id raw( 16 ) default sys_guid() ;
Example:
-- create a table without an id column
create table test_ ( str )
as
select dbms_random.string( 'x', 16 )
from dual
connect by level <= 10 ;
select * from test_ ;
STR
ULWL9EXFG6CIO72Z
QOM0W1R9IJ2ZD3DW
YQWAP4HZNQ57C2UH
EETF2AXD4ZKNIBBF
W9SECJYDER793MQW
alter table test_
add id raw( 16 ) default sys_guid() ;
select * from test_ ;
STR ID
ULWL9EXFG6CIO72Z 0x782C6EBCAE2D7B9FE050A00A02005D65
QOM0W1R9IJ2ZD3DW 0x782C6EBCAE2E7B9FE050A00A02005D65
YQWAP4HZNQ57C2UH 0x782C6EBCAE2F7B9FE050A00A02005D65
EETF2AXD4ZKNIBBF 0x782C6EBCAE307B9FE050A00A02005D65
W9SECJYDER793MQW 0x782C6EBCAE317B9FE050A00A02005D65
Testing
-- Are the id values unique and not null? Yes.
alter table test_
add constraint pkey_test_ primary key ( id ) ;
-- When we insert more rows, will the id be generated? Yes.
begin
for i in 1 .. 100
loop
insert into test_ (str) values ( 'str' || to_char( i ) ) ;
end loop ;
end ;
/
select * from test_ order by id desc ;
-- last 10 rows of the result
STR ID
str100 0x782C806E16A5E998E050A00A02005D81
str99 0x782C806E16A4E998E050A00A02005D81
str98 0x782C806E16A3E998E050A00A02005D81
str97 0x782C806E16A2E998E050A00A02005D81
str96 0x782C806E16A1E998E050A00A02005D81
str95 0x782C806E16A0E998E050A00A02005D81
str94 0x782C806E169FE998E050A00A02005D81
str93 0x782C806E169EE998E050A00A02005D81
str92 0x782C806E169DE998E050A00A02005D81
str91 0x782C806E169CE998E050A00A02005D81
Regarding your other questions:
{1} Then I'd like to know what PL SQL programmer typically do to ID records after importing a file. Do they do that? The main purpose for me to ID these records is to trace it back after manipulation/copying.
-> As you know, the purpose of an id is: to identify a row. We don't "do anything to IDs". Thus, your usage of IDs seems legit.
{2} Again, I understand there is solution there, my further question is whether PL SQL programmer actually do that, or there is other alternative which making this step not necessary in PL SQL?
-> Not quite sure what you are asking here. Although there is a ROWID() pseudocolumn (see documentation), we should not use it to identify rows.
"You should not use ROWID as the primary key of a table. If you delete
and reinsert a row with the Import and Export utilities, for example,
then its rowid may change. If you delete a row, then Oracle may
reassign its rowid to a new row inserted later."
Like to get some views from you all, regarding one scenario i'm struggling with currently. Below is a problem statement
I have Table A , B , C
A has below column
user|modified date| wokred_on A | ..some more related to user operation
B has columns
user | modified date | worked on B | ..some other columns
C has columsn
user | modified date | worked on C| ..some other columns
these tables are not have any direct relation except then user.
we have to pull data from these tables for a user between given dates with the count op action or work he has done between a given date range?
my struggle here is these each table has it's own date modified if a date range selected which is not in other column but still i need to pull the data as user has worked on it in between dates.
can it be possible to select these dates and have the in one column so that one can put that in where clause and having outer joins to pull other records ?
Sorry for this big problem statement. any suggestions are very much appreciated
Below is a use case.just extending the assumption given by littlefoot
First, test case:
SQL> create table a (cuser varchar2(10), modified_date date,action );
varchar2 (10) )
Table created.
SQL> create table b (
Table created.cuser varchar2(10), modified_date date,action
varchar2 (10) );
SQL> create table c (cuser varchar2(10), modified_date date,action
varchar2 (10) ));
Table created.
SQL> insert into a values ('lf', date '2018-05-01', 'issue raised');
1 row created.
SQL> insert into a values ('mc', date '2018-05-01', 'issue raised ');
1 row created.
SQL> insert into b values ('lf', date '2018-05-01',issue raised');
1 row created.
SQL> insert into b values ('lf', date '2018-05-01','issue resolved');
1 row created.
SQL> insert into c values ('if', date '2018-05-28',' issue resolved');
1 row created.
SQL> insert into c values ('mc', date '2018-05-13','issue raised');
1 row created.
SQL> insert into c values ('mc', date '2018-05-13','issue resolved');
1 row created.
SQL> alter session set nls_date_format = 'yyyy-mm-dd';
Session altered.
SQL> select * from a;
CUSER MODIFIED_D. ACTION
---------- ----------
lf 2018-05-01 issue raised
mc 2018-05-01 issue raised
SQL> select * from b;
CUSER MODIFIED_D ACTION
---------- ----------. ______________
lf 2018-05-01 issue raised
lf 2018-05-01. issue resolve
SQL> select * from c;
CUSER MODIFIED_D. ACTION
---------- ----------
If 2018-05-28. issue resolve
mc 2018-05-13. issue raised
mc 2018-05-13. issue resolve
CUSER DATE CNT_ISSUE_RAISED CNT_ISSUE_RESOLVED
------ ------- --------------- -------------------
if 2018-05-01 2 1
lf 2018-05-28 0 1
mc 2018-05-01 0 1
mc 2018-05-13 1 1
This is how I understood the question.
First, test case:
SQL> create table a (cuser varchar2(10), modified_date date);
Table created.
SQL> create table b (cuser varchar2(10), modified_date date);
Table created.
SQL> create table c (cuser varchar2(10), modified_date date);
Table created.
SQL> insert into a values ('lf', date '2018-05-01');
1 row created.
SQL> insert into a values ('mc', date '2018-05-15');
1 row created.
SQL> insert into b values ('lf', date '2018-05-07');
1 row created.
SQL> insert into b values ('lf', date '2018-05-08');
1 row created.
SQL> insert into c values ('jw', date '2018-05-28');
1 row created.
SQL> insert into c values ('mc', date '2018-05-13');
1 row created.
SQL> insert into c values ('mc', date '2018-05-22');
1 row created.
SQL> alter session set nls_date_format = 'yyyy-mm-dd';
Session altered.
SQL> select * from a;
CUSER MODIFIED_D
---------- ----------
lf 2018-05-01
mc 2018-05-15
SQL> select * from b;
CUSER MODIFIED_D
---------- ----------
lf 2018-05-07
lf 2018-05-08
SQL> select * from c;
CUSER MODIFIED_D
---------- ----------
jw 2018-05-28
mc 2018-05-13
mc 2018-05-22
Query which returns desired result - number of rows per each user in every table, in desired date period. As I use SQL*Plus, variables are preceded by && to avoid multiple insert requests. In a tool you use, that might be a colon (:).
SQL> select nvl(nvl(a.cuser, b.cuser), c.cuser) cuser,
2 count(distinct a.modified_date) cnt_a,
3 count(distinct b.modified_date) cnt_b,
4 count(distinct c.modified_date) cnt_c
5 from a full outer join b on a.cuser = b.cuser
6 full outer join c on a.cuser = c.cuser
7 where a.modified_date between &&date_from and &&date_to
8 or b.modified_date between &&date_from and &&date_to
9 or c.modified_date between &&date_from and &&date_to
10 group by nvl(nvl(a.cuser, b.cuser), c.cuser)
11 order by 1;
Enter value for date_from: '2018-05-01'
Enter value for date_to: '2018-06-01'
CUSER CNT_A CNT_B CNT_C
---------- ---------- ---------- ----------
jw 0 0 1
lf 1 2 0
mc 1 0 2
SQL>
I need to create a view over a table and would not wish to change view each time table structure changes. Is there any such possibility? any pointers appreciated around this.
If you don't want to specify all the fields of your table, you can define a view with something like select *, even if I don't like such solution, but you always have to rebuild your view after a table alter.
For example:
SQL> create table yourTable ( a number, b number);
Table created.
SQL> insert into yourTable values ( 1, 2);
1 row created.
SQL> insert into yourTable values ( 10, 20);
1 row created.
SQL> create or replace view yourView as select * from yourTable;
View created.
The view works fine:
SQL> select * from yourView;
A B
---------- ----------
1 2
10 20
If you add a column, the view will not show it:
SQL> alter table yourTable add (c number);
Table altered.
SQL> select * from yourView;
A B
---------- ----------
1 2
10 20
You need to rebuild your view to have the new column:
SQL> create or replace view yourView as select * from yourTable;
View created.
SQL> select * from yourView;
A B C
---------- ---------- ----------
1 2
10 20
If you drop a column, your view will become invalid, and you need to rebuild it:
SQL> alter table yourTable drop column c;
Table altered.
SQL> select * from yourView;
select * from yourView
*
ERROR at line 1:
ORA-04063: view "ALEK.YOURVIEW" has errors
SQL> create or replace view yourView as select * from yourTable;
View created.
SQL> select * from yourView;
A B
---------- ----------
1 2
10 20