Versions Compared

Key

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

...

HandlerDescription
DISCARDIgnore the offending SQL and continue with the next one
FORCE

...

Ignore the conflict, leave the SQL applied and continue with the next one (this differs from DISCARD only if the SQL actually changes something, i.e. the conflict is "too many rows updated/deleted")
OVERWRITE

...

Do not check old values, try again with just primary key in the where clause (thus this will fail if there is no row at all on

...

APPLY with the PK value)
NEWER,OLDER

...

Look into target table (by primary key) and get values of specified columns (usually dates or number sequence). If the source row is newer/older, the operation becomes OVERWRITE, otherwise DISCARD.
PLSQL

...

Call user-

...

specified PL/SQL function.

...

f(apply_old_data table%rowtype, has_found_apply_row boolean, primary_key_data table%rowtype, new_data table%rowtype) return number;
The return values are:

    • 0: discard
    • 1: overwrite
    • 2: retry
    • 3: the PL/SQL function resolved the conflict by itself and made all necessary changes.

The function must not issue a commit, as the transaction may be yet rolled back, if a rollback happened on source.

See also Data available to apply sessions for further information available to the handler.

...

 More information is available in PL/SQL conflict handler section. 
SQLSpecify a regular expression to change the executed SQL. Note that

...

APPLY will still bind the same variables to execute the modified statement, so instead of simply commenting them out you can use e.g. nvl(1, :1) = 1 instead. Simple example: "s/$/ and rownum = 1/" will add the specified text to end of the SQL statement.
RETRY

...

Wait a few seconds (set by variable RETRY_TIME ) and try again
PAUSE

...

Wait for manual user resolution
ABORT

...

kill

...

APPLY process
ERROR

...

rollback the transaction, continue applying other transactions

 

 

Note
Note: all All the configured conflict handlers are listed in table: DBRSAPPLY_CONFLICT_HANDLERS. 
This has the same result running the command: dbvrep> SHOW_CONFLICT_HANDLERS

 

...