Informix Error -329: Database not found or no system permission.

Cause and resolution

Database not found or no system permission.

The database you tried to open is not visible to the database server. Check the spelling of the name. Possibly the database is located in a different database server (or network system), and you have omitted to specify the server name (or site name) with the database name. If you are sure the database should exist just as you spelled it, your next step depends on the database server you are using.

If you are using IBM Informix SE, the visible databases are directories with names in the form dbname.dbs. You must be able to read from and write to them. The database server looks first in the current working directory and then in each directory named in the DBPATH environment variable. The most common cause of this error is an incorrect setting or no setting for the DBPATH environment variable.

If you are using IBM Informix Dynamic Server, IBM Informix Universal Server, or IBM Informix OnLine Dynamic Server, the database does not exist as you spelled it. In some environments, two or more instances of the database server can run at once and each instance has its own collection of databases. For Version 6.0 and later, the value of the INFORMIXSERVER environment variable determines the instance of the database server that you use. For Versions 5.1x and earlier, the ONCONFIG environment variable points to the configuration file that determines the instance. See your database server administrator if you think you might be using the wrong instance.

If you are connected to a secondary database server, the database you tried to open might exist, but is not logged. Databases are required to be logged to be able to access them on secondary database servers.

Oninit® Troubleshooting Guidance

Reasons / Common Causes

-329 fires when the database named in a DATABASE/CONNECT statement isn't visible to the server at all — a broader failure than a simple typo, since it also covers configuration and topology issues that keep an otherwise-real database from being found.

A misspelled database name — the simplest and most common cause.
The database lives on a different database server or network node, and the statement didn't specify the server/site name needed to reach it.
On IBM Informix SE, an incorrect or missing DBPATH environment variable — SE relies on DBPATH to locate databases that aren't in the current directory.
The database genuinely doesn't exist under that name on Dynamic Server.
On a secondary (HDR/RSS) database server, an unlogged database — secondary servers can only see databases that are logged; an unlogged database on the primary won't be visible there.

Solutions / Resolution

Verify the database name's spelling, per the official guidance, as the first check.
If the database is on a different server, specify it explicitly:
```
DATABASE sales@remote_server;
```
On Informix SE, check the DBPATH environment variable for correctness and confirm it includes the database's actual location.
On Dynamic Server, confirm the database actually exists under that exact name, via dbaccess:
```
dbaccess sysmaster -
> SELECT * FROM sysdatabases;
```
On a secondary server, confirm the database is logged on the primary — an unlogged database won't replicate or be visible on secondaries at all.

Examples

Specifying a remote server explicitly

DATABASE sales;
-- -329: sales isn't on this server

DATABASE sales@remote_server;
-- succeeds if sales exists on remote_server and is reachable

Checking DBPATH on Informix SE

echo $DBPATH
-- confirm it includes the directory where the target database lives

Diagnostic Checks

Double-check the database name's spelling.
Confirm which server the database actually lives on, and whether the statement needs an explicit @server qualifier.
On Informix SE, check DBPATH.
On a secondary server, check whether the database is logged on the primary.

Related Errors / Related Topics

-310 — "Table table-name already exists in database." A related object-visibility condition, though at the table level within an already-connected database rather than the database level itself.

Don't assume a typo — check server topology, DBPATH (on SE), and logging status (on secondaries) before concluding the database name itself is wrong.