IN THIS SECTION
- Row Count Mismatch Analysis Rules
- Setting the Row Count Rule Configuration
- How the Row Count Rules Work
- The Row Count Rules
Row Count Mismatch Analysis Rules
The gold standard in a data test is when both Source and Target QueryPair members return the identical data with the same number of rows returning for both. By default, if there is a difference in the number of rows, or if there are Nonmatching rows either on the Source or the Target, this is grounds for QuerySurge to declare the test outcome as a failure.
However, there are some situations where you might not want a difference in the row counts between Source and Target to result in a Failed Outcome. For example, because of the ways your systems populate with data, there will regularly be differing row counts, and you might want QuerySurge to report a Warning outcome instead of a Failed Outcome when you know in advance that row counts will not match. In some cases, you might want QuerySurge to ignore differences in row counts altogether.
QuerySurge supports all of these options.
Setting the Row Count Rule Configuration
You set the configuration for each QueryPair on the QueryPair Properties tab:
Alternately, you can set the configuration for an entire folder by right-clicking on the folder and selecting “Bulk Row Count Rule Update…” on the menu. This will set the rule for all QueryPairs in the selected folder.
How the Row Count Rules Work
The basic concept in evaluating row count mismatches is that a row count mismatch can either be Source-based or Target-based.
A Source-based row count mismatch means that the Source Query returns more rows than the Target Query, but that they also have some number of rows in common that match.
In this example of Source-based row count mismatch, the Source and Target share 3 identical rows (K100 - K300), plus two rows with mismatched data (K400 - K500), and the Source has 1 row in excess of the Target:
A Target-based row count mismatch is just the opposite: the Target Query returns more rows than the Source Query, but they also have some number of rows in common that match.
In this example of a Target-based row count mismatch, the Source and Target share 3 matched and 2 mis-matched rows as above, but now the Target has 1 row in excess of the Source:
NOTE: Either of these conditions can occur in combination with data mismatches too.
The Row Count Rules
The Row Count Rules are summarized in the following table:
| Rule | Outcome Description | |
| 1 | Report Fail on Row Count Mismatches | Report a Failed Outcome when any row count mismatch occurs. This is the default setting for all QueryPairs when you create them. |
| 2 | Report Warning on Source Row Count Mismatches | Report a Warning when the Source has excess rows as compared with the Target. Report a Failed Outcome when the Target has excess rows as compared to the Source. |
| 3 | Report Warning on Target Row Count Mismatches | Report a Warning when the Target has excess rows as compared with the Source. Report a Failed Outcome when the Source has excess rows as compared to the Target. |
| 4 | Ignore Source Row Count Mismatches | Report a Passed Outcome when the Source has excess rows as compared with the Target. Report a Failed Outcome when the Target has excess rows as compared to the Source. |
| 5 | Ignore Target Row Count Mismatches | Report a Passed Outcome when the Target has excess rows as compared with the Source. Report a Failed Outcome when the Source has excess rows as compared to the Target. |
NOTE If you choose an “Ignore” Rule (Rule [4] or Rule [5] above), row count mismatches will be reported by QuerySurge as a Passed Outcome. This can be confusing, especially if you are working on a team and other coworkers may not be aware of how your QueryPairs are configured.