Check if table exists in SQL Server
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
When working with SQL Server, checking if a table exists before attempting to create, modify, or drop it is an essential practice. This can help prevent errors in scripts or applications due to attempting operations on non-existent tables. SQL Server provides several methods to verify the existence of a table in a database. Below, we explore these methods, their use-cases, and implications.
Utilizing the IF EXISTS Statement
With the introduction of SQL Server 2016, the IF EXISTS syntax was extended to be used in DROP and ALTER statements. It can also be employed within the CREATE statement using a conditional approach. Here’s how you can use IF EXISTS with different SQL operations:
Checking before dropping a table:
Using IF EXISTS directly in DROP statement:
This approach is cleaner and reduces the risk of errors since it checks and performs the operation in a single statement.
The OBJECT_ID Function
OBJECT_ID is a function that returns the database object identification number of a database object (like a table, view, or stored procedure) if it exists. Here’s an example of how it can be used:
In this script, 'dbo.MyTable' is the name of the table and 'U' designates a user table. If OBJECT_ID returns a non-null value, the table exists.
Querying the sys.tables System View
The sys.tables system catalog view contains a row for each table in a database. You can query this view to check if a table exists:
This method is straightforward and utilizes system views that are designed to be queried for metadata.
Using the INFORMATION_SCHEMA.TABLES View
Just like sys.tables, the INFORMATION_SCHEMA.TABLES view holds information about all tables and views within a database. To check for table existence:
This is particularly useful for ensuring compatibility across different types of SQL databases, as INFORMATION_SCHEMA views are standardized.
Tips and Considerations
- Performance: For large databases, consider the performance implications of repeatedly checking for table existence. Caching this information or designing less dynamic schema changes can mitigate performance hits.
- Permissions: Ensure that the executing account has the necessary permissions to query system views or use system functions.
- Use Case Specificity: Choose a method based on what other operations are being performed and what version of SQL Server is being used.
Summary Table
| Method | SQL Server Version | Usage Context |
| IF EXISTS in DROP/ALTER | 2016+ | Direct operation in DROP/ALTER |
| OBJECT_ID() | 2000+ | General presence check |
| sys.tables | 2005+ | Precise, internal use |
| INFORMATION_SCHEMA.TABLES | 1992+ (ANSI Standard) | Cross-SQL compatibility |
By understanding and utilizing these methods, you can ensure that operations involving table existence checks are efficient, error-free, and compatible with various SQL Server versions.

