Last updated on Dec 15, 2021



Action CollisionDetect causes HVR's integration to detect 'collisions', i.e. when a target row has been changed after the change that is being applied was captured. Collisions can happen during bi-directional replication; if the same row is changed to different values in databases A and B so quickly that there is no time to replicate the changes to the other database then there is danger that the change to A will be applied to B while the change to B is on its way to A. Collisions can also happen without bi-directional replication; if changes are made first to A and then to B, then the change to B could reach database C before the change from A reaches C. Undetected collisions can lead to inconsistencies; the replicated database will become more different as time passes.

The default behavior for CollisionDetect is automatic resolution using a simple rule; the most recent change is kept and the older changes discarded. The timestamps used have a granularity of one second; if the changes occur in the same second then one arbitrary location (the one whose name sorts first) will 'win'. Parameters are available to change this automatic resolution rule and to tune performance.

Collision detection requires that HVR maintains extra timestamp information for each tuple, unless parameter TimestampColumn is defined. This information is held in a special history table (named tbl__h). This table is created and maintained by both capture and integration for each replicated table. The old rows in this history table are periodically purged using timestamp information from the integrate receive timestamp table.

  • Action CollisionDetect is supported only for certain location classes depending on the parameter defined with the action. For the list of supported location classes, see the corresponding section for CollisionDetect in Capabilities.
  • Action CollisionDetect cannot be combined with the Burst Integrate method.


This section describes the parameters available for action CollisionDetect.





Treat a collision as an error instead of performing automatic resolution using the 'first wins' rule.

If parameter OnErrorSaveFailed in action Integrate is defined then the collision will be written to the fail table and the integration of other changes will continue. If parameter OnErrorSaveFailed is not defined then the integrate job will keep failing until the collision is cleared, either by deleting the row from the history table (using command hvrhistorypurge) or by deleting the transaction file in the HVR_CONFIG/router directory.



Exploit a timestamp column named col_name in the replicated table for collision detection. By relying on the contents of this column collision detection can avoid the overhead of updating the history table. Deletes must still be recorded.

One disadvantage of this parameter is that collision handling relies on this column being filled accurately by the application. Another disadvantage is that if there is more than one database where changes can occur then if a change occurs in the same second, then the collision cannot be detected properly.


Delete rows from history table once the receive stamp table indicates that they are no longer necessary for collision detection.

These rows can also be deleted manually using command hvrhistorypurge.



During row-wise refresh, discard updates if the timestamp value in colname is newer in the target then the source. This parameter can be used with hvrrefresh (option -mui) to reconcile the difference between two databases without removing newer rows from either.

This parameter must be used with parameter Context (e.g. Context=refresh).



Action only applies if refresh or compare context matches.