Informix Error -635: Not owner of object.

Reasons / Common Causes

-635 fires when attempting to drop a database object the current session doesn't own — the same general ownership restriction as -579's synonym-specific case, applied here to database objects more broadly (of which -634's trigger-not-found case is a related, more specific scenario once ownership itself isn't the issue).

1. A session attempting to drop an object created by a different user, without holding DBA privilege — the direct, only cause.
2. A cleanup/migration script running as an application user attempting to drop objects originally created by a different (often more privileged) account during initial setup.

Solutions / Resolution

1. Query the appropriate system catalog table to find the object's actual owner, per the official guidance — for example, systriggers for a trigger, systables for a table/view, sysindexes for an index.
2. Ask the object's owner, or a Database Administrator, to drop it, per the official guidance, if the current session isn't the owner.
3. Confirm which system catalog applies to the specific object type being dropped, since the owner column lives in a different catalog table depending on the object's kind.

Examples

Checking a trigger's owner

SELECT trigname, owner FROM systriggers WHERE trigname = 'trg_orders_update';

Checking a table/view's owner

SELECT tabname, owner FROM systables WHERE tabname = 'orders';

Diagnostic Checks

1. Identify the object's type (trigger, table, view, index, etc.) and query the matching system catalog table for its owner column.

Related Errors / Related Topics

• -579 — "Not owner of synonym." The same ownership restriction, specific to synonyms.
• -634 — "Object does not exist." A related error for the case where the named object isn't found at all, rather than found but not owned by the current session.

The general form of -579's ownership restriction — query the matching system catalog for the object's actual owner before assuming DBA involvement is needed.