Informix Error -971: Integrity violations detected.

Reasons / Common Causes

-971 fires in the violations-table / filtering-mode subsystem: it means a statement that should have succeeded cleanly instead found rows that violate a constraint or unique-index requirement, and a violations table is in place to catch them.

1. A SET CONSTRAINTS/SET INDEXES statement re-enabling (or setting to filtering mode) a disabled constraint or disabled unique index on a table that already has rows violating it, per the official guidance — the table's existing data doesn't satisfy the requirement being turned back on.
2. An INSERT, DELETE, or UPDATE against a table with a filtering-mode object, where the object's mode was set with the WITH ERROR option, and the statement itself encountered no other errors — per the official guidance, this combination routes violating rows into the violations table and returns -971 rather than failing the whole statement outright.
3. A violations table already started for the target table, per the official guidance — this error assumes one is in place to receive the inconsistent rows; without it, the underlying constraint or index failure would surface differently.

Solutions / Resolution

1. Inspect the violations table for the rows that failed the constraint or unique-index check — it holds exactly the data that's blocking the mode change or statement.
2. Correct or remove the offending rows, then retry the SET statement that re-enables or re-filters the constraint/index.
3. If the error came from a routine INSERT/UPDATE/DELETE against a table with WITH ERROR filtering-mode objects, treat -971 as informational: the statement completed and the violating rows were diverted, per the official guidance — check the violations table rather than assuming the whole statement failed.

Examples

Re-enabling a constraint against dirty data

ALTER TABLE customer MODIFY CONSTRAINT (cust_email_chk) DISABLED;
START VIOLATIONS TABLE FOR customer;
-- rows are inserted that would fail cust_email_chk while it's disabled
SET CONSTRAINTS (cust_email_chk) ENABLED;
-- -971: Integrity violations detected.
SELECT * FROM customer_vio;
-- shows the rows that don't satisfy cust_email_chk

Diagnostic Checks

1. Query the violations table (<table>_vio) associated with the target table to see the specific rows at fault.
2. Check the diagnostics table (<table>_dia), if started, for the specific constraint or index that each violating row failed.
3. Confirm whether WITH ERROR was specified on the SET/CREATE statement that put the object into filtering mode — it determines whether -971 accompanies a statement that otherwise succeeded, or blocks a mode change outright.

Related Errors / Related Topics

• -973 — "Cannot insert from the violations table to the target table." The specific failure when trying to copy corrected rows straight back from the violations table into a target that still has filtering-mode objects.
• -975 — "Invalid object and object mode combination." The general rule -971 is a data-driven instance of: an object/mode pairing that the current table contents don't support.
• -978 — "No insert permission on the violations/diagnostics tables." A privilege-level reason the same violations-table mechanism can fail, distinct from -971's data-content reason.

-971 means the violations-table mechanism did its job — it caught rows that don't satisfy a constraint or unique-index requirement. Check the violations table for the specific rows before assuming the whole operation failed.