Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 11 Next »

  • DISCARD: ignore 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-specied PL/SQL function. The function must have prototype:

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.

  • SQL: specify 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: all the configured conflict handlers are listed in table: DBRSAPPLY_CONFLICT_HANDLERS. 
This has the same result running the command: dbvrep> SHOW_CONFLICT_HANDLERS

 

See the Command Reference or use HELP SET_CONFLICT_HANDLERS for the exact syntax.
  • No labels