Oninit
Talk to an expert →

Informix Error -406

-406 Memory allocation failed.

Something in the current statement required the allocation of memory for data storage, but the memory was not available. Several things can cause this error. For example, your application has a memory leak, you are asking for more resources than the system is configured to allow, or a problem with UNIX requires that you reboot the system. On a client PC, if the INFORMIXDIR environment variable or some GLS file is missing, a connection attempt fails with this error message.

Rollback the current transaction. Look for ways to make this statement simpler or move less data. On UNIX, talk with the system administrator to solve memory problems or to look for ways to make the operating system give this program more virtual memory in which to run. On Windows, exit to the operating-system command line, free some disk space, and resubmit your program. On a client PC, make sure that the INFORMIXDIR environment variable is set and that all GLS files are available.

Oninit® Troubleshooting Guidance

Reasons / Common Causes

-406 fires when a statement needed to allocate memory for data storage and none was available — a genuine resource-exhaustion condition rather than a query-writing mistake, though the specific trigger varies by context.

  1. An application-level memory leak in the connecting client, gradually exhausting available memory over the life of a long-running process.
  2. Requesting more resources than the system/configuration allows — a genuinely large operation exceeding configured or physical memory limits.
  3. UNIX system-level resource issues — OS-level memory pressure, ulimit constraints, or swap exhaustion.
  4. On client PCs specifically, a missing INFORMIXDIR environment variable or missing GLS (Global Language Support) files during connection attempts — a configuration issue that manifests as this memory error rather than a clearer connection-setup message.
Solutions / Resolution
  1. On client PCs, first verify INFORMIXDIR is set correctly and GLS files are present, per the official guidance — this is a specific, checkable configuration issue distinct from genuine memory exhaustion.
  2. Check the connecting application for memory leaks, especially if the error appears only after the application has been running for a long time.
  3. Check whether the operation genuinely requires more memory than configured/available, and whether server-side memory configuration parameters need adjustment.
  4. Check UNIX-level resource limits (ulimit, available swap) on the server host.
Examples
Checking client-side environment on a PC connection failure
echo %INFORMIXDIR%
-- confirm it's set and points to a valid installation with
-- GLS files present, before assuming a genuine memory shortage
Checking for application-level memory growth over time
-- Monitor the connecting application's memory usage over its
-- lifetime; a leak pattern (steadily growing usage) points to
-- the application itself rather than server-side configuration.
Diagnostic Checks
  1. On client PCs, check INFORMIXDIR and GLS file presence first.
  2. Check the connecting application for a memory-leak pattern.
  3. Check UNIX-level resource limits on the server host.
  4. Check whether the specific operation is unusually large/memory-intensive relative to normal workloads.
Related Errors / Related Topics
  • -402 — "Address of a host variable is NULL." A related client-side/embedded-SQL structural error, though about pointer validity rather than memory exhaustion.
  • -347 — "Could not open table for exclusive access." Another resource-constraint-related error, in this case about the lock table rather than general memory.

On client PCs, check INFORMIXDIR and GLS files before assuming genuine memory exhaustion — a missing environment variable is a specific, easily overlooked cause of this exact error there.