DROP TABLE (Transact-SQL)
Removes one or more table definitions and all data, indexes, triggers, constraints, and permission specifications for those tables. Any view or stored procedure that references the dropped table must be explicitly dropped by using DROP VIEW or DROP PROCEDURE. To report the dependencies on a table, use sys.dm_sql_referencing_entities.
DROP TABLE [ database_name . [ schema_name ] . | schema_name . ] table_name [ ,...n ] [ ; ]
Is the name of the database in which the table was created.
Is the name of the schema to which the table belongs.
Is the name of the table to be removed.
DROP TABLE cannot be used to drop a table that is referenced by a FOREIGN KEY constraint. The referencing FOREIGN KEY constraint or the referencing table must first be dropped. If both the referencing table and the table that holds the primary key are being dropped in the same DROP TABLE statement, the referencing table must be listed first.
Multiple tables can be dropped in any database. If a table being dropped references the primary key of another table that is also being dropped, the referencing table with the foreign key must be listed before the table holding the primary key that is being referenced.
When a table is dropped, rules or defaults on the table lose their binding, and any constraints or triggers associated with the table are automatically dropped. If you re-create a table, you must rebind the appropriate rules and defaults, re-create any triggers, and add all required constraints.
If you delete all rows in a table by using DELETE tablename or use the TRUNCATE TABLE statement, the table exists until it is dropped.
Large tables and indexes that use more than 128 extents are dropped in two separate phases: logical and physical. In the logical phase, the existing allocation units used by the table are marked for deallocation and locked until the transaction commits. In the physical phase, the IAM pages marked for deallocation are physically dropped in batches. For more information, see Dropping and Rebuilding Large Objects.
If you drop a table that contains a VARBINARY(MAX) column with the FILESTREAM attribute, any data stored in the file system will not be removed.
DROP TABLE and CREATE TABLE should not be executed on the same table in the same batch. Otherwise an unexpected error may occur.
Requires ALTER permission on the schema to which the table belongs, CONTROL permission on the table, or membership in the db_ddladmin fixed database role.
A. Dropping a table in the current database
The following example removes the ProductVendor1 table and its data and indexes from the current database.
DROP TABLE ProductVendor1 ;
B. Dropping a table in another database
The following example drops the SalesPerson2 table in the AdventureWorks database. The example can be executed from any database on the server instance.
DROP TABLE AdventureWorks.dbo.SalesPerson2 ;
C. Dropping a temporary table
The following example creates a temporary table, tests for its existence, drops it, and tests again for its existence.
USE AdventureWorks; GO CREATE TABLE #temptable (col1 int); GO INSERT INTO #temptable VALUES (10); GO SELECT * FROM #temptable; GO IF OBJECT_ID(N'tempdb..#temptable', N'U') IS NOT NULL DROP TABLE #temptable; GO --Test the drop. SELECT * FROM #temptable;
Added note about not dropping and creating the same table in a single batch.