Informix Error -171: ISAM error: ISAM file format change detected.

Reasons / Common Causes

-171 means a program using one locking method or index-node size is trying to access an ISAM file built with different settings — almost always the result of migrating data files between platforms without the corresponding conversion step. Unlike most format-mismatch conditions in this range, this one has a specific, documented, actionable fix rather than pointing at corruption.

1. Migrating ISAM data files (.dat/.idx) between platforms with different index-node sizes — a platform-specific ISAM implementation detail that the file's internal structure encodes, and the new platform's library doesn't automatically reconcile.
2. Migrating between platforms or configurations with different locking methods, specific to IBM Informix SE or C-ISAM — the file's internal locking-method marker doesn't match what the current environment expects.
3. Copying raw .dat/.idx files directly from one system to another during a migration, without running the platform-appropriate conversion step afterward.
4. Restoring an old backup created on a different platform or version without accounting for these platform-specific format differences.

Solutions / Resolution

The fix depends on which mismatch actually applies:

1. For platform migration with different index-node sizes: run bcheck or secheck with the -s option against all ISAM files (.dat and .idx) to resize index nodes to match the current platform.
2. For IBM Informix SE with different locking methods: set the RESETLOCK environment variable to convert ISAM files as they're accessed, or run UPDATE STATISTICS in the database as an alternative that touches (and thereby converts) all files at once.
3. For C-ISAM applications migrating between platforms with different locking methods: set RESETLOCK to convert files as they're accessed during the migration.
4. Plan for this conversion step explicitly as part of any platform migration involving ISAM/C-ISAM data — don't copy raw files and assume they'll work unchanged on the new platform.
5. Verify conversion completed for every relevant file, not just the ones an application happens to touch first — otherwise this error can resurface intermittently as different files get accessed for the first time after the migration.

Examples

Resizing index nodes after a platform migration

bcheck -s customer.dat customer.idx
secheck -s orders.dat orders.idx

Run this against every migrated ISAM file, not just the first one that triggers -171.

Converting locking method via RESETLOCK

export RESETLOCK=1
# Access each file (or run a program that touches it) so the
# conversion happens as part of normal access

Converting everything at once via UPDATE STATISTICS

UPDATE STATISTICS;

For Informix SE, this touches every file in the database, converting each as it's accessed — useful as a single step rather than tracking down every individual file.

Diagnostic Checks

1. Determine whether this is an index-node-size mismatch or a locking-method mismatch based on the specific platforms and product (Informix SE vs. C-ISAM) involved in the migration.
2. Check whether RESETLOCK is set in the environment, if a locking-method mismatch is suspected.
3. Review migration history and timeline to correlate the onset of this error with a recent platform change or restore.

Related Errors / Related Topics

• -100 — "ISAM error: duplicate value for a record with unique key." The other foundational ISAM-level error in this family.
• -105 — "ISAM error: bad ISAM file format." A different kind of file-format problem — -105 is genuine corruption requiring repair or restore; -171 is a platform-format mismatch with a specific, documented conversion fix, not corruption at all.

This is a conversion step, not a corruption to repair — identify which specific mismatch applies (index-node size or locking method) and run the matching fix from the official guidance.