Informix Error -165: ISAM error: TEXT or BYTE column does not exist.

Reasons / Common Causes

-165 is flagged by the official text as another internal error that "should not occur" — the database server called the internal isbcreate function against a column the catalog doesn't actually define as BYTE/TEXT. Same general category as -160/-161: check the one plausible application-level source before treating this as purely engine-internal.

1. An internal engine-level inconsistency between what a call believes about a column's type and its actual catalog definition — the condition the official text describes directly.
2. A schema change interacting badly with in-flight operations or cached query plans. An ALTER TABLE that changes a column's type away from BYTE/TEXT, combined with a prepared statement or cached plan still referencing the old column type, could plausibly produce this kind of mismatch.
3. Application code directly using ESQL/C large-object creation APIs (isbcreate) against the wrong column reference — the direct application-level analog to this condition, if the affected code path uses low-level BLOB creation calls itself.
4. Catalog inconsistency, rare, causing the engine's own understanding of a column's type to be wrong.

Solutions / Resolution

1. If this recurs, note all circumstances and contact IBM Informix Technical Support, per the official guidance — framed as an internal condition without a documented general fix.
2. If application code directly calls isbcreate() via ESQL/C, review the column reference being passed to confirm it actually targets a BYTE/TEXT column.
3. If this appeared right after a schema change altering a column's type, check whether cached query plans or prepared statements need to be re-prepared against the current schema rather than reused from before the change.
4. Capture full circumstances — the statement involved and recent schema history — for escalation if application-level review doesn't reveal a cause.

Examples

Reviewing an ESQL/C column reference

/* Confirm the column actually being targeted is defined as BYTE or TEXT */
isbcreate(fd, column_number, ...);

If column_number doesn't correspond to an actual BYTE/TEXT column in the current schema, that mismatch is the fix to make — correct the reference to target the right column.

A schema change interacting with a stale prepared statement

-- Column was BYTE, an application held a prepared statement referencing it
ALTER TABLE documents MODIFY (content VARCHAR(500));
-- content is no longer BYTE/TEXT

-- The application's stale prepared statement, still referencing the
-- old column definition, may need to be re-prepared rather than reused

Diagnostic Checks

1. Review whether application code directly uses isbcreate(), and confirm the column reference passed actually targets a BYTE/TEXT column in the current schema.
2. Check for a recent schema change to the column in question, and whether cached/prepared statements were re-prepared afterward.
3. Capture full circumstances for escalation if the cause isn't found in application-level BLOB API usage or recent schema changes.

Related Errors / Related Topics

• -100 — "ISAM error: duplicate value for a record with unique key." The other foundational ISAM-level error in this family.
• -160 — "ISAM error: only one TEXT or BYTE field may be open at any time." Part of the same general category of internal TEXT/BYTE handling conditions the official documentation flags as unexpected.

Check for a recent schema change to the column in question first — a stale prepared statement or cached plan referencing an old column definition is the most plausible non-engine-internal explanation.