Informix Error -389
-389 No DBA permission.
This statement cannot be executed because you have not been granted DBA privilege for this database. Contact a person who has DBA privilege for the database and ask to be granted DBA privilege (or simply ask to have this statement executed for you).
It is also possible that you received this message because you tried to register a user-defined routine that is written in a language for which you do not have usage privilege. If you do not have usage privilege for the language, ask one of the following users to grant this privilege to you: user informix or another user who has been granted the privilege with the option to grant the privilege to other users.
Oninit® Troubleshooting Guidance
Reasons / Common Causes
-389 is the top tier of the database-level privilege hierarchy (CONNECT < RESOURCE < DBA):
a statement genuinely requires DBA-level privilege on the database, and the current user doesn't
have it.
- A statement requiring DBA privilege (certain administrative operations, dropping other users' objects, and similar) attempted by a non-DBA user.
- Registering a user-defined routine in an unsupported/external language, which requires
language-usage privilege — typically held only by the
informixuser or someone explicitly granted it — rather than DBA privilege on the database itself. - A user who was previously a DBA on this database, but had that privilege revoked, breaking a previously-working workflow.
Solutions / Resolution
- Contact a DBA to grant DBA privilege, per the official guidance, if the statement
genuinely needs it:
GRANT DBA TO app_user; - Alternatively, have the statement executed on the requester's behalf by someone who already holds DBA privilege, rather than escalating privileges broadly.
- For user-defined-routine registration in an unsupported language, request that the
informixuser (or another user already holding language-usage privilege) grant that specific access, rather than assuming DBA privilege alone will resolve it.
Examples
Granting DBA privilege
GRANT DBA TO app_user;
Having a DBA execute the statement instead of escalating
-- Rather than granting broad DBA privilege to a service account,
-- have an existing DBA run the one-off administrative statement
-- directly.
Diagnostic Checks
- Confirm whether the failing statement is a UDR registration in an unsupported language, which needs language-usage privilege specifically, not just DBA.
- Check whether the user previously had DBA privilege that was since revoked.
Related Errors / Related Topics
- -388 — "No resource permission." The next tier down in the same database-level privilege
hierarchy (
CONNECT<RESOURCE<DBA). - -387 — "No connect permission." The base tier of the same privilege hierarchy.
Check which of the two distinct scenarios applies — DBA privilege for most cases, or
language-usage privilege (typically from the informix user) specifically for registering
routines in unsupported languages.