SQLCODE -545: Row violates a check constraint

What it means

A check constraint is a condition every row in a table has to meet, such as CHECK (SALARY >= 0) or CHECK (STATUS IN ('A','C','X')). Db2 tests it each time a row is inserted or changed. If the new row makes the condition false, Db2 rejects the statement with -545 and the table is left unchanged.

A condition that comes out unknown counts as passed. A comparison with a null value is unknown, so a null usually gets through a check constraint unless the rule tests for null itself.

The message gives only the constraint name, not the column or the value. If the DDL didn't name the constraint, Db2 generated a name, so look it up in the catalog rather than guessing from the name. The definition is in SYSIBM.SYSCHECKS.

Common causes

• The input has a value outside the allowed set, such as a status code nobody told the DBA about.
• The application added a new code value, but the check constraint still lists only the old ones.
• A program moves spaces or zeros into a column when the input is missing, and the constraint doesn't allow them.
• An UPDATE changes one column of a rule that spans two, for example a new START_DATE that is later than the existing END_DATE.
• The constraint was added recently and an older program still writes values it now rejects.
• The update branch of a MERGE changes a row into one that fails the rule.

How to find the problem

1. Take the constraint name from the message and read the rule with SELECT TBOWNER, TBNAME, CHECKCONDITION FROM SYSIBM.SYSCHECKS WHERE CHECKNAME = 'ORDSTATCK'.
2. Display the host variables the program used for the failing statement and test them against the rule by hand.
3. For an UPDATE, select the current row too. A rule across two columns can fail because of the value that wasn't changed.
4. Check the date the constraint was created, from CREATEDTS in SYSIBM.SYSCHECKS, if a long-running program suddenly started failing.

How to fix it

• Correct the input data and run the statement again.
• If the rule is out of date, have the DBA drop the constraint and add a corrected one with ALTER TABLE.
• Validate values in the program before the INSERT or UPDATE, so a bad record gets a clear message instead of -545.
• Agree code lists between the application team and the DBA, so a new value goes into the constraint before it goes into the data.

What it looks like

ORDENTRY - UPDATE ORDER_HDR FAILED, ORDER 00047113
DSNT408I SQLCODE = -545, ERROR:  THE REQUESTED OPERATION IS NOT ALLOWED BECAUSE A ROW DOES NOT SATISFY THE CHECK CONSTRAINT ORDSTATCK
DSNT418I SQLSTATE   = 23513 SQLSTATE RETURN CODE

Technical reviewer: Albert Joseph, WND Software.

Last reviewed 2026-10-18 by the WND Software team. Written in our own words. For the full reference, check IBM’s Db2 for z/OS documentation for your release.