Versions Compared

Key

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

...

 

Panel
bgColorCCC
DELETE from SCOTT."REQUESTS" 
where (1=1)
and ID = 3567
and TYPE IS NULL
and VERSION = 4
and STATE IS NULL
and STATUS = 'A' 
and NAMES_PACEID = 1 
and STATUSLASTMODIFIEDSTATUS_LASTMODIFIED = to_timestamp('2013.0806.2312 1713:3940:3818.788000000360000000', 'yyyy.mm.dd hh24:mi:ss.ff') 
and NAMESPACEID = 1
and ISRELATIVE IS NULL
and RELATIVEBASEDATERELATIVE_STATUS = 3
and ACCEPTEDDATETIMEACCEPTED_DATETIME = to_timestamp('2013.0806.2312 1714:39:3821.000000000', 'yyyy.mm.dd hh24:mi:ss.ff')
Error: Command affected 0 row(s). 
Handled as: RETRY 
Conflict repeated 11789 times.

 

Then this query can be turned into a SELECT statement that can be run manually on the target database:

Panel
bgColorCCC
SELECT * from SCOTT."REQUESTS" 
where (1=1) 
and ID = 3567
and TYPE IS NULL
and VERSION = 4
and STATE IS NULL
and STATUS = 'A' 
and NAMES_PACEID = 1 
and STATUSLASTMODIFIEDSTATUS_LASTMODIFIED = to_timestamp('2013.0806.2312 1713:3940:3818.788000000360000000', 'yyyy.mm.dd hh24:mi:ss.ff') 
and NAMESPACEID = 1
and ISRELATIVE IS NULL
and RELATIVEBASEDATERELATIVE_STATUS = 3
and ACCEPTEDDATETIMEACCEPTED_DATETIME = to_timestamp('2013.0806.2312 1714:39:3821.000000000', 'yyyy.mm.dd hh24:mi:ss.ff');

This query will also return 0 rows when it is run on the target as it has the same conditions as the delete statement which caused the conflict. 

...

Panel
bgColorCCC
SELECT * from SCOTT."REQUESTS" 
where (1=1) 
and ID = 3567
and TYPE IS NULL
and VERSION = 4
and STATE IS NULL
and STATUS = 'A' 
and NAMES_PACEID = 1 
and STATUSLASTMODIFIEDSTATUS_LASTMODIFIED = to_timestamp('2013.0806.2312 1713:3940:3818.788000000360000000', 'yyyy.mm.dd hh24:mi:ss.ff') 
and NAMESPACEID = 1
and ISRELATIVE IS NULL
and RELATIVEBASEDATERELATIVE_STATUS = 3
;

If this now returns a record on the target database, then the data conflict is due to predicate that has just been removed. In this case "ACCEPTEDDATETIME"

...