Sum Troubleshooting
Common problems when creating and running a Sum check, their causes, and how to resolve them.
Validation Fails When Creating the Check
Clicking Validate returns an error instead of a success message.
Cause: The rule could not run against the selected data. The most common reasons are an invalid Filter Clause expression, a connection problem with the source, or a container that failed to load.
Resolution:
- Review the error message: it explains what needs attention.
- Check the Filter Clause for typos: it must be a valid SQL
WHEREexpression for the selected container. - If the message says the container is marked as Unloadable, the container was skipped after repeated operation failures. Follow the steps in Unloadable Container Error.
The Total Is Off by a Tiny Fraction
The reported sum differs from the expected value only in the last decimals.
Cause: The comparison is an exact equality and the column holds values that went through division or currency conversion, which do not add up to a round figure.
Resolution: Reconcile on a whole-number column instead (units, or an amount stored in cents), or use Aggregation Comparison, which compares with an operator rather than a fixed equality.
The Check Passed but Rows Are Missing
The total matches even though records were lost.
Cause: Sum only proves the values add up. Rows that cancel out, or a missing row offset by a duplicated one, leave the total unchanged.
Resolution: Add a row-level rule alongside it. Volumetric watches the record count, and Unique catches duplicated keys.
Empty Values Are Not Reported
Rows where the field is empty do not cause a failure.
Cause: An empty value contributes nothing to the total, exactly like a zero. The rule cannot tell the two apart.
Resolution: Add Not Null on the same field so a missing value is reported in its own right.
The Coverage Slider Has No Effect
Lowering coverage does not stop the check from failing.
Cause: The slider is part of the shared check form, but Sum compares one aggregate against one value. There is no per-row pass rate for it to relax.
Resolution: Adjust the expected Sum, or scope the rows with a Filter Clause, instead of changing coverage.
The Anomaly Lists No Source Records
Opening the anomaly shows the two totals but no rows.
Cause: The rule raises a column-level Shape Anomaly. No single row is wrong, so there is nothing to list.
Resolution: Read the two numbers to size the gap, and pair the check with a per-row rule when you need to act on individual records.
An Edited Check Keeps Behaving the Old Way
You changed the configuration but the anomaly list did not change.
Cause: Edits take effect on the next Scan. Saving the check does not re-evaluate the data, and anomalies raised under the previous configuration are not modified.
Resolution: Run a Scan on the container (or wait for the scheduled one). Old anomalies stay open until you triage them or a Full scan with Auto Resolve clears them. See What Happens to Existing Anomalies.
No Anomalies Although the Data Looks Wrong
A Scan ran, the data clearly breaks the rule, but nothing was reported.
Cause: One of these configurations is excluding the violations:
- The check is in Draft status: Draft checks are not evaluated by Scans.
- The Filter Clause excludes those rows before the evaluation runs.
Resolution: Confirm the check is Active and test the filter expression against the offending rows.