-185 - accessor-id HAS NO action-type AUTHORITY ON object

SQL Codes › SQL Return Codes -1 through -999 › -185 - accessor-id HAS NO action-type AUTHORITY ON object

-185 - accessor-id HAS NO action-type AUTHORITY ON object

Explanation

The accessor ID identified in the message text does not have the required privilege to execute the identified action on the identified object. This error message is generated in different situations with different values substituted for action-type in the message text, as described in the following chart.

Note: External security is the preferred method for securing all SQL resources.

Plan security authorizations (CHECKBINDER, PLAN EXECUTE, PLAN BIND) are checked using the following criteria. If any external security path is active, external security is checked. Otherwise, SQL GRANT/REVOKE security is checked. If neither security method is active but an attempt is made to use SQL plan security anyway, the authorization attempt is rejected as if security had been active and the user was unauthorized.

The SQLSTATE that equates to this SQL return code is 42501.

Note: You cannot use SQL to do maintenance on the DATA-DICT database, that is, no maintenance can be done to any tables in the DATA-DICT database using SQL. For details about DATA-DICT, see the CA Datacom/DB Database and System Administration Guide.

Action-type Value	Explanation	User Response
SELECT, UPDATE, DELETE, INSERT, ALTER, or READ	You do not have the authority (per CA Datacom/DB Security) to execute the SQL statement. The name of the table or view on which you were attempting the operation replaces object in the message text.	If the statement causing the error is a SELECT, INSERT, DELETE, or ALTER function, someone with authority for the object must give you authority with a GRANT statement. This person can be the original creator of the table or view or someone to whom authority was granted with the WITH GRANT option. If the statement that caused the error is a LOCK TABLE statement, the required authority depends on the security mode of the database in which the table resides. If the table resides in a database with SQL security, SELECT authority is required to lock the table in SHARE mode, and UPDATE authority is required to lock the table in EXCLUSIVE mode. To execute the statement, someone with authority to execute a GRANT statement for the object must give you authorization. If table being locked is in a database with CA Datacom/DB security, READ authority is required to lock the table in EXCLUSIVE mode. To execute LOCK TABLE, someone who is an owner of the table must grant you the required authority using the CA Datacom/DB Security Facility.
DROP	You do not have the required authority (per CA Datacom/DB Security) to execute the DROP statement. The object (view, table, index, or synonym) is in the error message.	Under the SQL Security Model, only the original creator of a table, view, or synonym may drop that object. For tables, however, there is an exception: any user identified in the Security Facility as an owner of that table may drop it. Note: A user also qualifies as an owner of a table if the user is a Global Owner or an owner of the database in which table resides. To drop an index you must have the INDEX privilege for the indexed table. Under the CA Datacom/DB Security Model, you must have the CATALOG access right for the database containing the table to drop the table or to drop an index from the table.
CREATE TABLE	You do not have the required authority (per CA Datacom/DB Security) to execute the CREATE TABLE statement. The area in which the table was to reside is identified in the error message.	You may create a table in an area (through SQL) only if you have the CATALOG access right for that database. These authorities can be granted only through the Security Facility.
COMMENT ON	You do not have the required authority (per CA Datacom/DB Security) to execute the SQL statement.	To execute COMMENT ON, you must be the original creator of the table or view, or, if the object is a table, an owner of the table (per the Security Facility).
GRANT SELECT, GRANT DELETE, GRANT INSERT, GRANT UPDATE, or GRANT ALTER	You do not have the required authority (per CA Datacom/DB Security) to execute the SQL statement.	To grant an authority, the user must possess that authority. To execute GRANT, someone with the authority to grant it to you must execute the GRANT statement.
REVOKE	You do not have the required authority to execute the SQL statement. To revoke an authority from someone, you must first have granted that authority to him.	A Global Owner can revoke any authority from anyone, even if that Global Owner did not personally grant the authority. If the grantor of the authority cannot execute the REVOKE, this method can be used to revoke the authority on the grantor's behalf.