Defining the Restrict Action With a RefreshCondition Parameter Results in Data Discrepancies
Issue
After running a Refresh job on a subset of table data by defining the Restrict action with the RefreshCondition parameter, the target table becomes out of sync with the source.
Environment
HVR 6
Resolution
To resolve this issue, do the following:
- In the top-right menu of the Channel Details page, click Refresh Data.
- In the Refresh Data dialog, expand the Online refresh consistency when selecting tables which are being changed drop-down menu.
- Select the checkbox next to Online refresh controls to affect replication of changes that occurred before and during refresh.
- Below the checkbox, select the option No changes are skipped, but changes before end of refresh are integrated with resilience.
For more information, see our Refresh Options documentation.
Cause
Refresh jobs account for pending and in-flight changes that the Capture job captures before or during the Refresh job. Integrate jobs typically skip these changes safely as we move them to the target during Bulk Refresh or Row-by-Row Refresh.
However, when you define the Restrict action with the RefreshCondition parameter, changes outside the filter are excluded, resulting in target table inconsistencies.