Skip to content

Min Length Troubleshooting

Common problems when creating and running a Min Length 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.

Empty Strings Are Flagged and You Expected Them to Pass

Rows holding an empty string are reported.

Cause: An empty string is a present value with length zero, so it is measured like any other value and fails any positive minimum. Only NULL passes automatically.

Resolution: This is usually the desired behavior. When empty strings should be treated as missing, normalize them to NULL upstream.

A Value That Looks Too Short Is Not Flagged

A value that looks shorter than the minimum passes the check.

Cause: Leading or trailing whitespace counts toward the length and is invisible in most viewers, so a padded value measures longer than it looks. Fixed-width extracts often pad every value to the column width, which can carry a value over the minimum on padding alone. Whitespace can only push a value over a minimum, never under it, so it never causes a Min Length failure.

Resolution: Compare the measured length echoed in the anomaly message against what you expect. Trim the value upstream or with a Computed Field so the check measures the real content.

Rows With NULL Values Are Not Flagged

Rows with an empty field pass the check.

Cause: This is by design: NULL values pass. Min Length only measures present values. Note that an empty string is not NULL: it has length zero and is evaluated normally.

Resolution: Pair the check with a Not Null check on the same field to also require presence.

An Array Row Behaves Unexpectedly

An array field is evaluated as a whole rather than element by element.

Cause: Array Element Context is off, so the check measures the array field itself instead of each element.

Resolution: Turn on Array Element Context to measure each element separately.

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

Resolution: Confirm the check is Active and test the filter expression against the offending rows. Then 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.