Row Count Mismatches

Versions: 8.0+

 

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.

TOP OF PAGE

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.

 TOP OF PAGE

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:

NOTEObviously, either of these conditions can occur in combination with data mismatches too.

TOP OF PAGE

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.

TOP OF PAGE