You can grant permissions on the following database objects:
A user with DBA authority or the owner of the table can grant permission on tables and/or on individual table columns. For a list of the permissions that can be granted on tables, see Permissions.
You can grant permissions on tables using the GRANT statement or using the database object's Permissions tab in Sybase Central. See Grant permissions to users.
A user with DBA authority or the owner of the view can grant permission on the view. For a list of the permissions that can be granted on views, see Permissions.
A user can obtain DELETE, INSERT, SELECT, and UPDATE permissions on a view when one or more of the following are true:
A user with DBA authority or the user who owns the view explicitly granted the permissions.
The user has the appropriate permissions for the operation on all the underlying objects (for example, base tables, views, and procedures) used in the view.
The user was granted appropriate permissions for the operation on the view by a non-DBA user. This user must be either the owner of the view or have WITH GRANT OPTION of the appropriate permissions on the view. The owner of the view must be either:
a user with DBA authority.
a user that does not have DBA authority, but who is the owner of all the base tables referred to by the view.
a user that does not have DBA authority, and is not the owner of some or all the base tables referred to by the view. However, the view owner has SELECT permission WITH GRANT OPTION on the base tables not owned and any other required permissions WITH GRANT OPTION on the base tables not owned for the operation.
Instead of the owner having permissions WITH GRANT OPTION on the base tables, permissions may have been granted to PUBLIC, including SELECT permission on system tables.
You can grant permissions on disabled views. Permissions for disabled views are stored in the database and become effective when the view is enabled.
A user with DBA authority or the owner of the procedure can grant permission on a stored procedure. The EXECUTE permission is the only permission that may be granted on a procedure.
Execution permissions of procedures Procedures execute with the permissions of their owner. Any procedure that updates information in a table executes successfully only if the owner of the procedure has UPDATE permission on the table.
As long as the procedure owner has the proper permissions, the procedure executes successfully when called by any user assigned permission to execute it, whether they have permissions on the underlying table. You can use procedures to allow users to perform well-defined activities on a table, without having any general permissions on the table.
A user with DBA authority or the owner of the trigger can grant permission to execute triggers. The EXECUTE permission is the only permission that can be granted on a trigger.
The database server executes triggers in response to a user action. Once the EXECUTE permission has been granted on a trigger, the trigger does not require further permissions to execute. When a trigger executes, it does so with the permissions of the owner of the table with which it is associated.
A user with DBA authority can grant permission to create objects on specified dbspaces. The user that is granted permission on dbspaces must have RESOURCE authority. The CREATE ON permission is the only permission that can be granted on dbspaces.
A user with DBA authority or the creator of the sequence can grant permission to execute the sequence. The USAGE permission is the only permission that is granted on sequence generators. This permission allows users to evaluate the current or next value in a sequence. If the sequence is part of a DEFAULT clause on a table, any user that inserts a row into the table must have permission on the sequence.
Discuss this page in DocCommentXchange.
|
Copyright © 2012, iAnywhere Solutions, Inc. - SQL Anywhere 12.0.1 |