Informix Error -268: Unique constraint <constraint-name> violated. </constraint-name>

Reasons / Common Causes

-268 is the named-constraint-specific sibling of -100 and -239 — the mechanism is identical (a duplicate value in a protected column), but the constraint here is a named UNIQUE CONSTRAINT object rather than a bare unique index. Both -100 and -239 already point here for the fuller constraint-specific framing; this entry covers what's distinct about -268 itself.

1. A duplicate value introduced into a column or columns protected by a named unique constraint — the direct cause, mechanically identical to -100/-239's causes (see those entries for the full range: check-then-insert races, SERIAL collisions, non-idempotent loads, index-vs-application value-normalization mismatches).
2. An isolation-level inversion worth knowing precisely. Under most isolation levels, a named unique constraint violation reports directly as -268. Under Repeatable Read isolation specifically, this same condition instead surfaces as -239 — which is exactly why -239's own guidance says to refer to -268 when running under that isolation level. The two codes describe the same underlying event; which one you actually see depends on isolation level.

Solutions / Resolution

1. On IBM Informix Dynamic Server, understand that any changes this statement made prior to discovering the duplicate are automatically rolled back. Unlike some errors in this catalogue, there's no partial-modification risk to worry about here — the official text is explicit about this rollback happening automatically.
2. Find the existing row and apply -100's fix strategies — overwrite, skip, surface the conflict to a human, fix a SERIAL collision, or fix ETL idempotency, depending on the actual cause identified.
3. If running under Repeatable Read isolation, expect this same condition to surface as -239 instead — read both entries together for full context if you're troubleshooting under that isolation level specifically.

Examples

Diagnosing which constraint was violated

-- The constraint name is embedded directly in the error message,
-- but confirm its definition:
SELECT constrname, constrtype FROM sysconstraints
WHERE constrname = 'the-constraint-name-from-the-error';

The isolation-level inversion

-- Under Committed Read (or most other isolation levels):
INSERT INTO customer (id, email) VALUES (2, 'a@example.com');
-- -268: named constraint cust_email_uq violated

SET ISOLATION TO REPEATABLE READ;
INSERT INTO customer (id, email) VALUES (2, 'a@example.com');
-- -239 instead, for the exact same underlying violation

See -100 for the full range of realistic causes and fixes — they apply here without modification once the constraint-vs-index distinction is understood.

Diagnostic Checks

1. Identify the specific named constraint directly from the error message.
2. Query sysconstraints for the constraint's definition and the columns it protects.
3. Check the isolation level in use if you expected -268 but saw -239 instead (or vice versa) — that's the documented inversion, not a different problem.
4. Follow -100's diagnostic queries (adapted to query sysconstraints alongside sysindexes) to find the specific conflicting row.

Related Errors / Related Topics

• -100 — "ISAM error: duplicate value for a record with unique key." The ISAM-level foundational sibling — nearly all of -268's realistic causes and fixes live there.
• -239 — "Could not insert new row - duplicate value in a UNIQUE INDEX column." The isolation-level counterpart — under Repeatable Read, the exact same named-constraint violation reports as -239 instead of -268.

If you expected -268 but got -239 (or vice versa), check the isolation level in use before assuming a different problem — that's the documented, known inversion between these two codes.