Oninit
Talk to an expert →

Informix Error -164: ISAM error: TEXT or BYTE stamp is incorrect.

Cause and resolution

ISAM error: TEXT or BYTE stamp is incorrect.

This operation has returned an invalid BYTE or TEXT value. Possibly the data pages have been corrupted. Roll back the current transaction. Have the database server administrator use tbcheck -D, oncheck -D, or onutil to get more information about the problem.

If the program is operating with Dirty Read or Committed Read isolation, this code might indicate that another process or thread has deleted the BYTE or TEXT value and its pages have been partly reallocated to an unrelated value. A program using Dirty Read isolation can read rows that have been deleted if the deletion has not yet been committed. If the deletion is committed while the program is reading a BYTE or TEXT value, and if the space allocated to the value is reused for some other program, this error code might be returned.

When a program uses Committed Read isolation, it does not see a row that has been marked for deletion; however, no lock is placed on a row that is not read for update. BYTE or TEXT data is read in a second step, after the row has been fetched. During this lengthy step, it is possible for another program to delete the row and commit the deletion and for the storage space to be reused. To determine if this has occurred, the program should stop processing the BYTE or TEXT value and reread the row. If the program can no longer read the other fields in the row, the row has been deleted. If the program can still read the row, the storage space is corrupted.

Oninit® Troubleshooting Guidance

Reasons / Common Causes

-164 has the same dual-cause shape as -126: it can mean genuine data-page corruption affecting a BYTE/TEXT value, or it can be a transient timing artifact under weaker isolation levels — and distinguishing the two is the actual diagnostic task, not assuming the more alarming explanation by default.

  1. Genuine data-page corruption affecting the stored BYTE/TEXT value — the same general family as -105 and -163.
  2. A concurrent delete racing a read, under Dirty Read or Committed Read isolation. The official text explains this directly: another process deleting the BYTE/TEXT value while it's being read can cause the underlying pages to be reallocated. A concurrent reader following a now-stale reference finds mismatched stamp data — not because anything is actually corrupted, but because the page it's looking at has been reused for something else entirely.
  3. Concurrent DML replacing the value (an UPDATE, not just a DELETE) potentially causing the same kind of page-reallocation timing issue under weaker isolation levels.
  4. The same general corruption causes as -105/-163 (unclean shutdown, hardware failure, an improper backup) if genuine corruption is confirmed rather than a timing artifact.
Solutions / Resolution
  1. Roll back the current transaction, per the official guidance.
  2. Have the database administrator use oncheck -cd (tbcheck on IBM Informix OnLine) to check the table's data pages for genuine corruption.
  3. For the Dirty Read/Committed Read scenario specifically: stop processing and reread the row to determine whether the value was legitimately deleted or whether genuine corruption is actually present. This is the official guidance's own recommended first step, and it's the fastest way to rule the timing explanation in or out.
  4. If the reread confirms the row was legitimately deleted by the concurrent process, treat this as expected, transient behavior under weak isolation — not corruption, and not something requiring further investigation.
  5. If the reread and further check-utility investigation confirm genuine corruption, follow the same root-cause investigation and potential-restore path as -105/-163.
  6. If this timing-related occurrence is frequent and disruptive, consider whether a stricter isolation level is warranted for workloads reading BYTE/TEXT data concurrently with deletion-heavy activity — the same trade-off -126 describes for Dirty Read generally.
Examples
The concurrent-delete timing artifact
SET ISOLATION TO DIRTY READ;
-- Session A begins reading a large TEXT value

-- Meanwhile, Session B deletes the row, and its pages get reallocated
-- for other use

-- Session A's read continues against now-repurposed pages:
-- -164: the stamp doesn't match what was expected

Rereading the row (under a fresh, current read) reveals the row is genuinely gone — this is Dirty Read's known trade-off working as expected, not corruption.

Confirming genuine corruption
oncheck -cd mydb:documents

Run this once a reread has ruled out the timing explanation — if the row still exists and the value is still reported as invalid, this points at real page-level corruption rather than a concurrent-delete artifact.

Diagnostic Checks
  1. Reread the row first — this is the single most useful check, distinguishing legitimate concurrent deletion from genuine corruption before anything else.
  2. Check the isolation level in use for the failing read — Dirty Read or Committed Read makes the timing explanation far more plausible.
  3. Run oncheck -cd/tbcheck for further diagnosis if the reread doesn't resolve the ambiguity.
  4. If genuine corruption is suspected, follow -105/-163's diagnostic path — correlate against a recent crash, check hardware health on the underlying storage.
Related Errors / Related Topics
  • -126 — "ISAM error: bad row id." The closest sibling in structure — both have a common, usually-benign timing-related cause (Dirty Read racing a concurrent change) alongside a rarer, genuinely serious corruption cause, and the same "reread first" diagnostic approach applies to both.
  • -105 — "ISAM error: bad ISAM file format." The corruption-severity sibling for when the timing explanation is ruled out.

Reread the row before assuming corruption — a large share of -164 occurrences under Dirty Read or Committed Read resolve immediately once you confirm the row was simply deleted by someone else.