Oninit
Talk to an expert →

Informix Error -302

-302 No GRANT option or illegal option on multi-table view.

This GRANT statement cannot be executed. The grantor does not have the right to grant the specified privilege for this table, the table name is a synonym, or the table is a view for which this option cannot be granted. If the grantor does have the right to grant the privilege, the table in question might be a synonym or a view that is not modifiable and cannot be used for insert, update, or delete operations. Starting with version 9.40, you can define an INSTEAD OF trigger on the view to make it modifiable and then try this option.

To grant any privilege for a table, you must be the owner of the table or you must have been granted the same privilege with the GRANT option. To use the AS GRANTOR clause, you must have DBA privilege.

Oninit® Troubleshooting Guidance

Reasons / Common Causes

-302 covers a few distinct situations that all surface through the same message: the GRANT can't proceed either because the grantor genuinely lacks the authority, or because the target itself isn't a plain modifiable table.

  1. The grantor doesn't own the table and wasn't given the privilege WITH GRANT OPTION — to grant a privilege, you must either own the table or hold that privilege re-grantably yourself.
  2. The name given is actually a synonym, not the underlying table — privileges have to be granted against the real table (or view), not a synonym pointing to it.
  3. The name given is a non-modifiable view — specifically a multi-table view, which by default can't have INSERT/UPDATE/DELETE privileges granted on it the way a base table can.
Solutions / Resolution
  1. Confirm the grantor actually owns the table, or holds the privilege with WITH GRANT OPTION, per the official guidance — ownership or an explicit re-grantable privilege is required.
  2. If the name is a synonym, resolve it to the underlying table or view first, and grant against that instead.
  3. If the target is a multi-table view that genuinely needs to support INSERT/UPDATE/ DELETE privileges, add an INSTEAD OF trigger to it (supported as of version 9.40) — this makes the view modifiable and enables granting those privileges.
  4. Otherwise, grant the privilege on the view's underlying base tables directly, if modifying the view itself isn't an option.
Examples
Attempting to grant on a synonym
CREATE SYNONYM cust FOR customers;
GRANT SELECT ON cust TO report_user;
-- -302: cust is a synonym, not the underlying table

Fix — grant against the real table:

GRANT SELECT ON customers TO report_user;
Making a multi-table view modifiable with INSTEAD OF (9.40+)
CREATE VIEW customer_orders AS
    SELECT c.customer_id, c.name, o.order_id, o.total
    FROM customers c, orders o
    WHERE c.customer_id = o.customer_id;

GRANT UPDATE ON customer_orders TO app_user;
-- -302: a multi-table view isn't modifiable by default

CREATE TRIGGER customer_orders_upd INSTEAD OF UPDATE ON customer_orders
    REFERENCING NEW AS new OLD AS old
    FOR EACH ROW (
        UPDATE orders SET total = new.total
        WHERE order_id = old.order_id
    );
-- now the view is modifiable, and the GRANT can succeed
GRANT UPDATE ON customer_orders TO app_user;
Diagnostic Checks
  1. Confirm table/view ownership and whether the grantor holds the privilege WITH GRANT OPTION if they don't own it.
  2. Check whether the target name resolves to a synonym rather than the base table or view.
  3. Check whether the target is a multi-table view without an INSTEAD OF trigger, if granting a modification privilege.
Related Errors / Related Topics
  • -298 — "Cannot grant permission to public with grant option." Another GRANT-clause restriction in the same privilege-management family.
  • -299 — "Cannot grant permission to self." A related sibling in the same GRANT-validation family.

Three separate root causes share this one message — check ownership/grant-option first, then whether the name is a synonym, then whether it's a non-modifiable multi-table view.