Transact-SQL Syntax ConventionsTransfers a securable between schemas.
Transact-SQL Syntax Conventions
-- Syntax for SQL Server and Azure SQL Database
ALTER SCHEMA schema_name
TRANSFER [ <entity_type> :: ] securable_name
[;]
<entity_type> ::=
{
Object | Type | XML Schema Collection
} -- Syntax for Azure SQL Data Warehouse and Parallel Data Warehouse
ALTER SCHEMA schema_name
TRANSFER [ OBJECT :: ] securable_name
[;] schema_name
Is the name of a schema in the current database, into which the securable will be moved. Cannot be SYS or INFORMATION_SCHEMA.
<entity_type>
Is the class of the entity for which the owner is being changed. Object is the default.
securable_name
Is the one-part or two-part name of a schema-scoped securable to be moved into the schema.
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.
Moving a stored procedure, function, view, or trigger will not change the schema name, if present, of the corresponding object either in the definition column of the sys.sql_modules catalog view or obtained using the OBJECT_DEFINITION built-in function. Therefore, we recommend that ALTER SCHEMA not be used to move these object types. Instead, drop and re-create the object in its new schema.
Moving an object such as a table or synonym will not automatically update references to that object. You must modify any objects that reference the transferred object manually. For example, if you move a table and that table is referenced in a trigger, you must modify the trigger to reflect the new schema name. Use sys.sql_expression_dependencies to list dependencies on the object before moving it.
To change the schema of a table by using SQL Server Management Studio in Object Explorer, right-click on the table and then click Design. Press F4 to open the Properties window. In the Schema box, select a new schema.
[!CAUTION]
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)](../relational-databases/system-catalog-views/catalog-views-transact-sql.md).
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 IMPERSONATE permission on the owner of the target schema.
All permissions associated with the securable that is being transferred are dropped when it is moved.
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 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 The following example creates a table Region in the dbo schema, creates a Sales schema, and then moves the Region table from the dbo schema to the Sales schema.
CREATE TABLE dbo.Region
(Region_id int NOT NULL,
Region_Name char(5) NOT NULL)
WITH (DISTRIBUTION = REPLICATE);
GO
CREATE SCHEMA Sales;
GO
ALTER SCHEMA Sales TRANSFER OBJECT::dbo.Region;
GO CREATE SCHEMA (Transact-SQL)
DROP SCHEMA (Transact-SQL)
EVENTDATA (Transact-SQL)