ALTER AUTHORIZATION (Transact-SQL)

ALTER AUTHORIZATION (Transact-SQL)

Switch on low bandwidth view

Community Content

In this section

Statistics Annotations (0)

Click here to expand

Collapse All

Language Filter

Other versions are also available for the following:

SQL Server 2005

SQL Server 2008 Books Online (June 2009)

ALTER AUTHORIZATION (Transact-SQL)

Updated: 26 February 2009

Changes the ownership of a securable.

Topic link icon Transact-SQL Syntax Conventions

Syntax

ALTER AUTHORIZATION
   ON [ <class_type>] entity_name
   TO { SCHEMA OWNER | principal_name }

<class_type> ::=
    {
        OBJECT | ASSEMBLY | ASYMMETRIC KEY | CERTIFICATE 
    | CONTRACT | TYPE | DATABASE | ENDPOINT | FULLTEXT CATALOG 
        | FULLTEXT STOPLIST | MESSAGE TYPE | REMOTE SERVICE BINDING
       | ROLE | ROUTE | SCHEMA | SERVICE | SYMMETRIC KEY 
        | XML SCHEMA COLLECTION
    }

Arguments

<class_type>: Is the securable class of the entity for which the owner is being changed. OBJECT is the default.

entity_name: Is the name of the entity.

principal_name: Is the name of the principal that will own the entity.

Remarks

ALTER AUTHORIZATION can be used to change the ownership of any entity that has an owner. Ownership of database-contained entities can be transferred to any database-level principal. Ownership of server-level entities can be transferred only to server-level principals.

Important:
Beginning with SQL Server 2005, a user can own an OBJECT or TYPE that is contained by a schema owned by another database user. This is a change of behavior from earlier versions of SQL Server. For more information, see User-Schema Separation, OBJECTPROPERTY (Transact-SQL), and TYPEPROPERTY (Transact-SQL).

Ownership of the following schema-contained entities of type "object" can be transferred: tables, views, functions, procedures, queues, and synonyms.

Ownership of the following entities cannot be transferred: linked servers, statistics, constraints, rules, defaults, triggers, Service Broker queues, credentials, partition functions, partition schemes, database master keys, service master key, and event notifications.

Ownership of members of the following securable classes cannot be transferred: server, login, user, application role, and column.

The SCHEMA OWNER option is only valid when you are transferring ownership of a schema-contained entity. SCHEMA OWNER will transfer ownership of the entity to the owner of the schema in which it resides. Only entities of class OBJECT, TYPE, or XML SCHEMA COLLECTION are schema-contained.

If the target entity is not a database and the entity is being transferred to a new owner, all permissions on the target will be dropped.

Caution:
In SQL Server 2005, the behavior of schemas changed from the behavior in earlier versions of SQL Server. Code that assumes that schemas are equivalent to database users may not return correct results. Old catalog views, including sysobjects, should not be used in a database in which any of the following DDL statements has ever been used: CREATE SCHEMA, ALTER SCHEMA, DROP SCHEMA, CREATE USER, ALTER USER, DROP USER, CREATE ROLE, ALTER ROLE, DROP ROLE, CREATE APPROLE, ALTER APPROLE, DROP APPROLE, ALTER AUTHORIZATION. In a database in which any of these statements has ever been used, you must use the new catalog views. The new catalog views take into account the separation of principals and schemas that is introduced in SQL Server 2005. For more information about catalog views, see Catalog Views (Transact-SQL).

Caution:

In SQL Server 2005, the behavior of schemas changed from the behavior in earlier versions of SQL Server. Code that assumes that schemas are equivalent to database users may not return correct results. Old catalog views, including sysobjects, should not be used in a database in which any of the following DDL statements has ever been used: CREATE SCHEMA, ALTER SCHEMA, DROP SCHEMA, CREATE USER, ALTER USER, DROP USER, CREATE ROLE, ALTER ROLE, DROP ROLE, CREATE APPROLE, ALTER APPROLE, DROP APPROLE, ALTER AUTHORIZATION. In a database in which any of these statements has ever been used, you must use the new catalog views. The new catalog views take into account the separation of principals and schemas that is introduced in SQL Server 2005. For more information about catalog views, see Catalog Views (Transact-SQL).

Also, note the following:

Important:
The only reliable way to find the owner of a object is to query the sys.objects catalog view. The only reliable way to find the owner of a type is to use the TYPEPROPERTY function.

Special Cases and Conditions

The following table lists special cases, exceptions, and conditions that apply to altering authorization.

Class	Condition
DATABASE	Cannot change the owner of system databases master, model, tempdb, the resource database, or a database that is used as a distribution database. The principal must be a login. If the principal is a Windows login without a corresponding SQL Server login, the principal must have CONTROL SERVER permission and TAKE OWNERSHIP permission on the database. If the principal is a SQL Server login, the principal cannot be mapped to a certificate or asymmetric key. Dependent aliases will be mapped to the new database owner. The DBO SID will be updated in both the current database and in sys.databases.
OBJECT	Cannot change ownership of triggers, constraints, rules, defaults, statistics, system objects, queues, indexed views, or tables with indexed views.
SCHEMA	When ownership is transferred, permissions on schema-contained objects that do not have explicit owners will be dropped. Cannot change the owner of sys, dbo, or information_schema.
TYPE	Cannot change ownership of a TYPE that belongs to sys or information_schema.
CONTRACT, MESSAGE TYPE, or SERVICE	Cannot change ownership of system entities.
SYMMETRIC KEY	Cannot change ownership of global temporary keys.
CERTIFICATE or ASYMMETRIC KEY	Cannot transfer ownership of these entities to a role or group.
ENDPOINT	The principal must be a login.

Permissions

Requires TAKE OWNERSHIP permission on the entity. If the new owner is not the user that is executing this statement, also requires either, 1) IMPERSONATE permission on the new owner if it is a user or login; or 2) if the new owner is a role, membership in the role, or ALTER permission on the role; or 3) if the new owner is an application role, ALTER permission on the application role.

Examples

A. Transferring ownership of a table

The following example transfers ownership of table Sprockets to user MichikoOsada. The table is located inside schema Parts.

ALTER AUTHORIZATION ON OBJECT::Parts.Sprockets TO MichikoOsada;
GO

The query could also look like the following:

ALTER AUTHORIZATION ON Parts.Sprockets TO MichikoOsada;
GO

B. Transferring ownership of a view to the schema owner

The following example transfers ownership the view ProductionView06 to the owner of the schema that contains it. The view is located inside schema Production.

ALTER AUTHORIZATION ON OBJECT::Production.ProductionView06 TO SCHEMA OWNER;
GO

C. Transferring ownership of a schema to a user

The following example transfers ownership of the schema SeattleProduction11 to user SandraAlayo.

ALTER AUTHORIZATION ON SCHEMA::SeattleProduction11 TO SandraAlayo;
GO

D. Transferring ownership of an endpoint to a SQL Server login

The following example transfers ownership of endpoint CantabSalesServer1 to JaePak. Because the endpoint is a server-level securable, the endpoint can only be transferred to a server-level principal.

ALTER AUTHORIZATION ON ENDPOINT::CantabSalesServer1 TO JaePak;
GO

Change History

Updated content
Added ASYMMETRIC KEY to the list.
Corrected <entity_type> to <class_type>.

Special Cases and Conditions

A. Transferring ownership of a table

B. Transferring ownership of a view to the schema owner

C. Transferring ownership of a schema to a user

D. Transferring ownership of an endpoint to a SQL Server login

Reference

Other Resources

Help and Information