Skip to content

Any Not Null Troubleshooting

Common problems when creating and running an Any Not Null 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.

Rows With Empty Fields Are Not Flagged

Rows that look empty in the selected fields pass the check.

Cause: The rule tests for NULL, not for emptiness. A field holding an empty string, a space, or a placeholder such as n/a counts as populated, so the row passes.

Resolution: Normalize blank values to NULL upstream, or expose a Computed Field that maps them to NULL, then point the check at that field. To also enforce that the value is usable, pair the check with Matches Pattern on the same fields.

The Check Almost Never Fails

The check passes even on rows you expected to be reported.

Cause: The rule passes as soon as one selected field is populated. When the group includes a field that is almost always filled in (an ID, a created-at column, a default), that field satisfies the check for every row and the fields you care about are never enforced.

Resolution: Narrow the group to fields that are genuinely interchangeable alternatives. When a specific field must always be present, use a separate Not Null check on it instead.

Only One Field Is Selected

The check works, but it behaves like a different rule.

Cause: With a single field, "at least one of these is populated" is the same assertion as Not Null.

Resolution: Use Not Null for a single field: it states the intent clearly and produces a message about that field. Reserve Any Not Null for two or more alternatives.

An Edited Check Keeps Behaving the Old Way

You added or removed a field 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 the ones the updated rule no longer flags. See What Happens to Existing Anomalies.

No Anomalies Although Rows Are Empty

A Scan ran, rows clearly have nothing in the selected fields, but nothing was reported.

Cause: One of three 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.
  • Coverage is below 100% and the failing fraction stayed within the tolerance, so the check passed.

Resolution: Confirm the check is Active, test the filter expression against the empty rows, and review the coverage setting. See Coverage and Tolerance.

Expected One Anomaly per Row, Got a Single Rolled-Up One

Many rows failed, but the scan reported one Shape Anomaly instead of per-row Record Anomalies.

Cause: When the number of failing rows exceeds the scan's rollup threshold, the per-row findings are grouped into one rolled-up Shape Anomaly.

Resolution: This is expected behavior; the rolled-up anomaly carries sampled source records. To change the threshold, see Maximum Record Anomalies per Check.