Informix Error -114

Reasons / Common Causes

-114 is a legacy naming-length constraint: the ISAM processor enforces a 10-character maximum on the filenames it opens or creates, inherited from the original C-ISAM product's file-naming convention. It's almost always reached by code that constructs or passes a filename directly, rather than something an ordinary SQL application would hit through normal DDL.

1. A C-ISAM program passing a filename longer than 10 characters directly to isopen() or isbuild() — the straightforward case the official text describes.
2. Auto-generated filenames built from longer identifiers — a working/temp file name assembled from a timestamp, username, and process ID concatenated together can easily exceed 10 characters without the generating code ever having considered the limit.
3. Porting or migrating from a context that permits longer identifiers — SQL table and column names in modern Informix versions can be far longer (up to 128 characters, per -200's own limit), so code or tooling written with that in mind can be surprised when a lower-level direct ISAM call enforces a much older, much shorter constraint.
4. Environment or platform differences masking the limit until now — code that happened to work (through truncation, a different code path, or simple luck) on one platform or configuration can hit this hard limit for the first time after a move to a different environment enforcing it strictly.

Solutions / Resolution

1. Shorten the filename passed to isopen()/isbuild() to 10 characters or fewer — there's no override or configuration flag for this limit.
2. For auto-generated filenames, add explicit length validation before the ISAM call — truncate deliberately with a scheme that preserves uniqueness (a short hash or a numeric sequence) rather than relying on whatever length the generating logic happens to produce.
3. When porting from a context that allows longer names, add a translation layer that maps longer logical names to compliant short physical filenames — keep a lookup table if human-readable physical names matter for operational purposes.
4. Standardize a short-name generation convention across the codebase (for example, an 8-character base plus a 2-digit numeric suffix) so this constraint is designed around once rather than rediscovered independently in different modules.
5. If this surfaces from SQL or embedded engine internals rather than direct application code, treat it as environment- or version-specific and escalate with full details per the official guidance, rather than assuming application code is at fault.

Examples

The direct violation

int fd = isopen("customer_master_2026", ISINPUT);
/* -114: 20 characters, well over the 10-character limit */

int fd = isopen("cust_mstr", ISINPUT);   /* 9 characters — fine */

The auto-generated name that quietly grew too long

char fname[64];
snprintf(fname, sizeof(fname), "%s_%ld_%d", username, (long)time(NULL), getpid());
isopen(fname, ISINPUT);
/* -114 — the concatenation routinely produces well over 10 characters */

Fix: generate a short, guaranteed-unique name instead of concatenating human-readable identifying information directly:

char fname[11];
snprintf(fname, sizeof(fname), "t%08x", (unsigned)hash_of(username, time(NULL), getpid()));

Diagnostic Checks

1. Identify the exact filename that triggered the error and count its length — the failure itself doesn't include the offending name, so check the calling code's argument at the point of failure directly.
2. Search the codebase for filename-generation logic that feeds into isopen()/isbuild() calls, particularly anything that concatenates multiple pieces of information into one name.
3. Check for a recent migration or platform change if this appeared for the first time without a corresponding code change — the underlying names may have always been too long, with the previous environment simply not enforcing the limit the same way.

Related Errors / Related Topics

• -100 — "ISAM error: duplicate value for a record with unique key." The other foundational ISAM-level error in this family, though unrelated in cause — grouped here as background on how this error class is organized.

This is a hard, non-negotiable limit at the ISAM layer — the fix is always to shorten or regenerate the filename, never to look for a way around the constraint itself.