Refine pair-level logic only where defaults are not enough.
The Advanced tab is where Compare stops being a broad setup flow and becomes a precise reconciliation tool. It gives detailed control over selected table pairs, data type alignment, SQL filtering, and delta-based comparison windows.
What lives in Advanced
Summarizes all table pairs currently selected for reconciliation and their validation state.
Shows the type mappings used to normalize values before they are compared and hashed.
Opens detailed controls for columns, SQL conditions, and delta-based processing on a single pair.
Tables Overview Table
This view keeps the full reconciliation scope visible in one place. It helps users remove, disable, validate, or inspect table pairs before the run starts.
Controls whether a given table pair is included in the reconciliation run. Invalid pairs can be disabled automatically.
Displays the schema-based pair identifier and opens deeper pair-level configuration.
Shows the source table together with estimated size and detected column count.
Shows the paired target table together with estimated size and detected column count.
Reports how long metadata retrieval took, which helps expose slow objects or environments.
Lets the user remove a table pair entirely from the reconciliation setup.
Validation confirms compatible keys and column structures. The pair is ready for reconciliation.
Something requires review, such as partial column matching or another non-blocking inconsistency.
A critical issue such as missing keys or incompatible structures blocks the pair from running.
Data Types Table
Data type mapping exists to make the comparison fair. Values from different engines often need to be cast into the same canonical representation before they are hashed or compared value by value.
The Data Types table defines how source and target types are aligned so the same business value produces the same comparison result.
Same canonical string and identical hash. Compare treats the row as consistent.
Different canonical output and different hash. The row looks inconsistent even though the business value can still be the same.
Numeric precision Trailing zeros, scale, and rounding rules can alter canonical output.
Date and time values Formatting, time zones, and precision can cause false mismatches.
Character data CHAR vs VARCHAR, padding, and empty string handling need consistent rules.
Compare Pair Dialog
The dialog attached to a selected pair is divided into three tabs. Together they control column-level alignment, row filtering, and time-windowed comparison.
Pair columns manually, define reconciliation keys, and exclude fields that should not participate.
Filter rows through SQL conditions so only the relevant subset enters the comparison.
Compare only data that changed over time, which is ideal for cyclical or scheduled runs.
Columns
Automatically uses the primary key defined in the database.
Lets the user pick an available index as the reconciliation key.
Allows explicit manual selection of the key columns.
Column Name (Source / Target) Shows the matched source and target fields, with PK labels where relevant.
Key flags Marks whether a column belongs to the reconciliation key according to the selected key mode.
Data type mapping Shows the original type and the mapped comparison type on each side.
Conditional Processing
Users can choose a source or target column and define SQL conditions that decide which rows should enter the reconciliation scope.
Compare can validate the SQL expression and preview the rows that satisfy it, which reduces the chance of filtering the wrong slice of data.
Conditional Processing acts before reconciliation proper. It narrows the data scope before hashing, key checks, and delta logic are applied.
The selected column belongs to a unique index and is usually a strong candidate for filtering or key logic.
The column participates in several index paths and may need closer review.
The column is not indexed, which can affect performance and should be used deliberately.
Delta Processing
Delta Processing is built for repeated runs where scanning the entire table every time would be unnecessary. It focuses only on data changed within a selected time window.
Delta mode uses a replicated timestamp column to limit the comparison to records changed between two selected points in time.
Value source: User input, Get Value, or the previous T2
Run impact: Acts as the starting point for the current run.
Value source: User input or Get Value
Run impact: Defines the upper bound of the analyzed window.
Value source: Saved automatically by the system
Run impact: Becomes the next T0 in the following run.
Unchanged records stay outside the comparison window.
The run spends less time and infrastructure on stable data.
The handoff from T2 to the next T0 makes recurring validation much easier to automate.