Skip to content

Distinct Count Troubleshooting

Common problems when creating and running a Distinct Count 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:

  1. Review the error message: it explains what needs attention.
  2. Check the Filter Clause for typos: it must be a valid SQL WHERE expression for the selected container.
  3. 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.

An Equal To Check Fails on a Count That Looks Right

The message reports a count one or two off from the expected number.

Cause: The distinct count is approximate. On a high-cardinality column the algorithm's margin of error is enough to break an exact equality.

Resolution: Switch to a bounded comparison such as Greater Than Or Equal To or Less Than Or Equal To, or keep Equal To only for small, controlled columns where the approximation is exact in practice.

The Count Is Lower Than Expected on a Sparse Column

A column you know holds many values reports a small count.

Cause: NULLs are not counted as a distinct value, and a filter may be excluding most rows.

Resolution: Check the filter, and pair with Not Null when the emptiness is the real finding.

The Check Reports Nothing Although Values Repeat

Duplicates exist but the check stays green.

Cause: Distinct Count measures how many different values exist, not whether any repeats.

Resolution: Use Unique when repetition is what you want to catch.

There Is No Coverage Option

The form shows no Coverage slider.

Cause: The rule asserts one number about the dataset, so there is no per-row violation rate.

Resolution: No action needed. Scope the measurement with a filter instead.

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.