Informix Error -159: ISAM error: Collation sequence invalid.

Reasons / Common Causes

-159 is a locale/collation mismatch: the collation sequence being used to access an ISAM file either isn't supported or doesn't match the sequence the file was actually created with. This is the modern GLS (Global Language Support) counterpart to the legacy mechanism -117 describes — where -117 is obsolete, -159 is an active, current concern.

1. The file was created under one locale/collation, and the current client or session is configured with a different, incompatible one — the client's expected collation simply doesn't match what the file was actually built with.
2. Locale configuration drift between file creation and now — DB_LOCALE/CLIENT_LOCALE (or equivalent environment variables) changed since the file was created, or differ between the servers/environments involved.
3. Migrating or copying data files between servers with different default locale configurations, without accounting for the difference during the migration.
4. A client library or application not setting/respecting the correct locale environment variables, defaulting to something that doesn't match the file's actual collation.
5. OS-level locale package differences between systems — a locale available at file-creation time simply not installed, or installed differently, on a different host encountered later.
6. Porting or restoring data to a new environment where the required locale isn't properly installed or configured, even though the application intends to use the same one it always has.

Solutions / Resolution

1. Use islanginfo() to determine the actual language/collation of the ISAM file, per the official guidance — this is the direct, authoritative way to confirm what the file actually needs, rather than guessing from environment configuration alone.
2. Align the client/session's locale configuration (DB_LOCALE, CLIENT_LOCALE, or equivalent) with what the file actually requires, once identified.
3. For migrations or restores across environments, explicitly verify and match locale configuration between source and target — don't assume it transfers automatically along with the data.
4. Ensure required OS-level locale packages are installed and available on any new host before migrating or restoring data that depends on them.
5. Standardize locale configuration across environments (development, test, staging, production) to avoid this kind of drift surfacing as a surprise in only one specific environment.
6. If the collation genuinely needs to change going forward, that likely requires rebuilding the file or data under the new collation, rather than simply reconfiguring the client to match an old one — the right approach depends on whether the goal is matching the existing data or migrating it to a new collation.

Examples

Diagnosing the actual required collation

islanginfo(fname, &info);
/* compare info's reported language/collation against the current
   session's DB_LOCALE/CLIENT_LOCALE configuration */

Run this before changing anything — it tells you definitively what the file expects, rather than guessing based on what the environment happens to be configured for.

Locale drift after a migration

-- Source server: DB_LOCALE=en_us.8859-1
-- Target server, after a data migration: DB_LOCALE=en_us.utf8
-- -159: the migrated ISAM file was built under the source locale,
-- but the target session is configured for a different one

Aligning the target session's locale configuration with what islanginfo() reports for the migrated file (or deliberately rebuilding the data under the new locale, if that's the actual intent) resolves this.

Missing locale package on a new host

A restore to a newly provisioned host fails with -159 because the specific locale package the original data depends on was never installed on the new system — the fix is installing that locale package, not adjusting application-level configuration to work around its absence.

Diagnostic Checks

1. Run islanginfo() against the affected ISAM file to determine its actual collation and language.
2. Compare that against the current session's locale configuration (DB_LOCALE/CLIENT_LOCALE).
3. Review recent migrations or restores for locale configuration differences between source and target environments.
4. Check OS-level locale package availability on the current host if a mismatch is suspected to stem from a missing or different locale installation.

Related Errors / Related Topics

• -100 — "ISAM error: duplicate value for a record with unique key." The other foundational ISAM-level error in this family.
• -117 — "ISAM error: bad custom collating sequence." The legacy predecessor concern — -117 describes an obsolete mechanism current products don't generate; -159 is the active, current equivalent under GLS.

Run islanginfo() first, always — it turns a locale mismatch from a guessing exercise into a direct comparison between what the file needs and what's currently configured.