ALTER SCHEMA (Transact-SQL)
Transfers a securable between schemas.
Applies to: SQL Server (SQL Server 2008 through current version), Azure SQL Database.
Users and schemas are completely separate.
ALTER SCHEMA can only be used to move securables between schemas in the same database. To change or drop a securable within a schema, use the ALTER or DROP statement specific to that securable.
If a one-part name is used for securable_name, the name-resolution rules currently in effect will be used to locate the securable.
All permissions associated with the securable will be dropped when the securable is moved to the new schema. If the owner of the securable has been explicitly set, the owner will remain unchanged. If the owner of the securable has been set to SCHEMA OWNER, the owner will remain SCHEMA OWNER; however, after the move SCHEMA OWNER will resolve to the owner of the new schema. The principal_id of the new owner will be NULL.
To change the schema of a table or view by using SQL Server Management Studio, in Object Explorer, right-click the table or view and then click Design. Press F4 to open the Properties window. In the Schema box, select a new schema.
Beginning with SQL Server 2005, the behavior of schemas changed. As a result, code that assumes that schemas are equivalent to database users may no longer return correct results. Old catalog views, including sysobjects, should not be used in a database in which any of the following DDL statements have 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 such databases you must instead use the new catalog views. The new catalog views take into account the separation of principals and schemas that was introduced in SQL Server 2005. For more information about catalog views, see Catalog Views (Transact-SQL).
To transfer a securable from another schema, the current user must have CONTROL permission on the securable (not schema) and ALTER permission on the target schema.
If the securable has an EXECUTE AS OWNER specification on it and the owner is set to SCHEMA OWNER, the user must also have IMPERSONATION permission on the owner of the target schema.
All permissions associated with the securable that is being transferred are dropped when it is moved.
A. Transferring ownership of a table
The following example modifies the schema HumanResources by transferring the table Address from schema Person into the schema.
USE AdventureWorks2012; GO ALTER SCHEMA HumanResources TRANSFER Person.Address; GO
B. Transferring ownership of a type
The following example creates a type in the Production schema, and then transfers the type to the Person schema.
USE AdventureWorks2012; GO CREATE TYPE Production.TestType FROM [varchar](10) NOT NULL ; GO -- Check the type owner. SELECT sys.types.name, sys.types.schema_id, sys.schemas.name FROM sys.types JOIN sys.schemas ON sys.types.schema_id = sys.schemas.schema_id WHERE sys.types.name = 'TestType' ; GO -- Change the type to the Person schema. ALTER SCHEMA Person TRANSFER type::Production.TestType ; GO -- Check the type owner. SELECT sys.types.name, sys.types.schema_id, sys.schemas.name FROM sys.types JOIN sys.schemas ON sys.types.schema_id = sys.schemas.schema_id WHERE sys.types.name = 'TestType' ; GO