Informix Error -151: ISAM error: Illegal value in varchar length field.

Reasons / Common Causes

-151 is a storage-integrity condition, not an application-logic bug: the leading byte in a VARCHAR column's on-disk representation — which records the value's actual length — indicates a length greater than the column was ever defined to hold. The official text calls this an internal error, in the same family as -105's corruption-diagnosis posture rather than something normal application code paths should be able to trigger.

1. On-disk corruption affecting the length byte specifically — the same general corruption pathways as -105 (an unclean shutdown, hardware failure, an improperly taken hot copy), but manifesting narrowly as this one field being inconsistent rather than broader file damage.
2. Direct or external manipulation of raw data files — a tool writing to dbspace chunk files outside the engine's own management, or a byte-level restore/migration gone wrong, corrupting VARCHAR column data specifically.
3. An ALTER TABLE that changed a VARCHAR column's declared length (particularly shrinking it) not correctly handled — if the operation was interrupted, or an older code path didn't fully rewrite/validate existing rows against the new definition, some rows can be left with a length byte inconsistent with the current column definition.
4. Version skew during an upgrade or migration, where the internal representation of VARCHAR data differs between versions, and data written under one version is read incorrectly by a different one.

Solutions / Resolution

1. If this recurs, gather full diagnostic circumstances and contact IBM Informix Technical Support, per the official guidance — this is described as an internal error without an established, documented self-service fix.
2. Investigate the same corruption pathways as -105 if hardware or an unclean shutdown is suspected: check for a recent crash, hardware issues on the underlying storage, or an improperly taken backup/copy.
3. Run the appropriate check utility against the affected table to assess the scope of damage and possible repair options.
4. Review recent ALTER TABLE history on VARCHAR columns in the affected table if a length change is a candidate cause — confirm the operation completed successfully and that existing rows were properly validated against the new definition afterward.
5. Review recent upgrade or migration history if version skew is suspected — confirm the correct, supported upgrade path (including any required data-conversion utilities) was actually followed.
6. Stop any direct or external manipulation of dbspace chunk files outside the engine's own tools, if that's identified as a factor.

Examples

Diagnosing with the check utility

oncheck -pt mydb:customer

Run this to assess the scope of the problem — whether it's isolated to specific rows or pages, which informs whether targeted repair or a broader restore is the more appropriate path forward.

Correlating with a recent ALTER TABLE

ALTER TABLE customer MODIFY (notes VARCHAR(50));
-- previously VARCHAR(200) -- existing rows with longer stored values
-- need to be correctly handled by this operation, not left with a
-- length byte referencing the old, now-invalid maximum

If -151 appears on a table shortly after a VARCHAR length change, review whether that specific operation is implicated before assuming unrelated storage corruption.

Diagnostic Checks

1. Run the check utility against the affected table:

   oncheck -pt <database>:<table>
   

2. Check for a recent unclean shutdown or hardware issue coinciding with the failure's likely onset:

   grep -iE "abort|panic|shutdown" $INFORMIXDIR/online.log
   dmesg -T | grep -iE "error|i/o"
   

3. Review recent ALTER TABLE history on VARCHAR columns in the affected table.
4. Review recent upgrade or migration history for possible version-skew explanations.

Related Errors / Related Topics

• -105 — "ISAM error: bad ISAM file format." The closest sibling in cause and diagnostic posture — both are storage-integrity conditions calling for a check utility and root-cause investigation rather than an application-code fix.
• -126 — "ISAM error: bad row id." Another condition where index/storage damage (among other causes) can produce a failure that looks structural rather than logical.

Treat this as a storage-integrity investigation from the start, following the same diagnostic path as -105, rather than searching application code for a bug that produced the bad length value directly.