Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

This is possible by using the  _MINE_FIX_INVALID_DATE_NEW_VALUE setting.

For exampleExample: 

No Format
set _MINE_FIX_INVALID_DATE_NEW_VALUE = 77640101010101

This is the hex equivalent of 1900-01-01 00:00:00. If the source date is invalid, then the target date will be: 1900.01.01 00:00:00. For an update statement where the invalid date is part of the WHERE clause, the new value of date will also be used.


In the following example END_DATE contained an invalid date value and has been changed to a valid date:

Section
Column
width5%

 

Column
width95
panel No Format
bgColorCCC
DELETE from AVI."INVALID_DATE"


where (1=1)


and PID = 101


and ORDER_NUMBER = 200


and START_DATE = 2012.09.15 15:24:26


and END_DATE = 1900.01.01 00:00:00


Invalid date with valid time component

In the case where the time component is valid, but the date component is not valid, the following can be set:

No Format
set _MINE_FIX_INVALID_DATE_NEW_VALUE = 77640101FFFFFF


This value can be obtained by dumping the target columns - eg. select DUMP(START_DATE,16) from table;

This will keep the time component of the whole date but will only replace the date component with 1900.01.01.

...

Ensure we have the _MINE_FIX_INVALID_DATE_NEW_VALUE set:

Section
Column
width5%

 

Column
width95
Panel No Format
bgColorCCC
dbvrep> set _MINE_FIX_INVALID_DATE_NEW_VALUE = 77640101FFFFFF

The mine MINE process will have to be restarted after setting this to take affect.

...

Lets create a new table on the source database:

Section
Column
width5%

 

Column
width95
Panel No Format
bgColorCCC
create table invalid_date (


pid number,


order_number number,


start_date date,


end_date date


);


Now lets insert an invalid date with a correct time component into this table:

Section
Column
width5%

 

Column
width95
Panel No Format
bgColorCCC
export SOURCE_TNS=d112f

sqlplus -s avi/xxx@${SOURCE_TNS}<<SQL

truncate table invalid_date;
declare
   d

declare
   d date;

begin

dbms_stats.convert_raw_value('64640001182e0e', d);

insert into invalid_date values (601, 200, sysdate, d);

insert into invalid_date values (701, 200, sysdate, d);

end;

/

SQL


We will also update the row with PID=601:

Section
Column
width5%

 

Column
width95
panel No Format
bgColorCCC
sqlplus -s avi/xxx@${SOURCE_TNS}<<SQL
declare
   d

declare
   d date;

begin

dbms_stats.convert_raw_value('64640001162f0f', d);

update invalid_date set end_date = d where pid = 601;

end;

/

SQL


Now lets select from this table to see what we have at the source database:

Section
Column
width5%

 

Column
width95
panel No Format
bgColorCCC
sqlplus -s avi/xxx@${SOURCE_TNS}<<SQL

alter session set nls_date_format='YYYY.DD.MM HH24:MI:SS';

select PID, END_DATE from avi.invalid_date;

SQL


The result from the source table is as follows:

Section
Column
width5%

 

Column
width95
panel No Format
bgColorCCC
PID  END_DATE


---- -------------------


 601 0000.01.00 21:46:14


 701 0000.01.00 23:45:13


We can see that the date component is invalid, but the time component is correct.

TARGET


Dbvisit Replicate will replicate the changes and substitute them based on _MINE_FIX_INVALID_DATE_NEW_VALUE.
Now lets see what the actual result is on the TARGET database:
Section
Column
width5%

 

Column
width95
Panel
bgColorCCC


No Format
TO_CHAR(END_DATE,'Y

-------------------

1900-01-01 21:46:14

1900-01-01 23:45:13

DUMP(END_DATE,16)

--------------------------------------------------------------------------------

Typ=12 Len=7: 77,64,1,1,16,2f,f

Typ=12 Len=7: 77,64,1,1,18,2e,e


We see that the time component has been kept, but the date component has been set to 1900-01-01.