There is already an object named error 2714 is SQL Server’s message when a CREATE statement targets a name that already exists in the current scope, a table, a temp table, an index, or a constraint. The four usual causes are: the object genuinely already exists from a previous run, a temp table name is being reused within the same session or batch, a named constraint collides with one that already exists, or a migration script is re-running against a database it already migrated. The fix in every case is to check for existence before creating, drop the conflicting object first, or make the script safe to re-run.
This is a SQL Server-specific error message, and the fixes below are SQL Server syntax. Postgres and MySQL throw the same class of error under a different name and number, covered at the end, because the underlying causes, a re-run script, a name collision, session-scoped temp objects, are the same everywhere.
Table of contents
- What Error 2714 Actually Means
- Cause One: The Object Already Exists
- Cause Two: Temp Tables Reused Across Batch vs Session
- Cause Three: Constraint Name Collisions
- Cause Four: A Migration Tool Re-Running the Same Script
- The Fixes: IF EXISTS, OBJECT_ID, Renaming, and MERGE
- Postgres and MySQL Equivalents
- How this fits the rest of the stack
- FAQ
What Error 2714 Actually Means
SQL Server raises error 2714, There is already an object named in the database, when a CREATE TABLE, CREATE INDEX, or similar statement tries to create something whose name is already taken in the relevant scope. The message names the object; the cause is almost never that SQL Server is wrong about the collision, it is that the script assumed a clean database it was not given.
The error itself is not dangerous, nothing is corrupted or lost when it fires. The four causes below cover the situations that actually produce it, roughly in order of how often each one shows up.
Cause One: The Object Already Exists
The simplest cause: a table, view, or procedure with that exact name is already there, usually from a previous run of the same script, an earlier migration, or a manual CREATE someone ran and forgot about. Query the catalog to confirm before assuming anything more exotic is happening.
SELECT OBJECT_ID('dbo.Orders', 'U');A non-null result means the object exists. From there the decision is whether to drop it, rename the new one, or skip the creation step entirely, and that decision depends on whether the existing object holds data worth keeping. A script that always drops and recreates is fine for a build artefact; it is the wrong default for anything holding rows a previous run put there.
Cause Two: Temp Tables Reused Across Batch vs Session
A local temp table (#Orders) is scoped to the session that created it and disappears when the session ends or the connection closes. Within a single script run as multiple batches, separated by GO, if an earlier batch already created #Orders and a later batch tries to create it again without dropping it first, SQL Server reports the collision because the table is still live in that session.
This is the most common false alarm: the fix is not a deeper database problem, it is adding a DROP TABLE IF EXISTS before every CREATE TABLE for a temp table that might already exist from an earlier batch in the same script.
Cause Three: Constraint Name Collisions
Named constraints, primary keys, foreign keys, defaults, unique constraints, share a single namespace per database, not per table. Two tables cannot both have a constraint named PK_Id unless SQL Server auto-generates unique names for you, which it does not do when the name is specified explicitly in the CREATE TABLE statement.
This surfaces most often when a table is copied and pasted as a starting point for a new one, constraint names included, and the new CREATE TABLE runs against a database where the old constraint name is already taken. Auto-generated constraint names avoid this entirely, at the cost of a less readable name in error messages later.
Cause Four: A Migration Tool Re-Running the Same Script
Entity Framework migrations, Flyway, and similar tools track which migrations have already run, but that tracking can get out of sync with the actual schema, a migration marked as not-yet-applied that actually already ran, a manually edited migration history table, or a rollback that dropped the tracking row but not the objects it created.
The fix here is less about the CREATE statement and more about reconciling the migration tool’s history table with what is actually in the database before letting it run again. Compare the migrations the tool believes are applied against the objects that actually exist, and correct whichever record is wrong before re-running anything.
The Fixes: IF EXISTS, OBJECT_ID, Renaming, and MERGE
- DROP TABLE IF EXISTS #Orders, the modern, one-line guard before a temp table CREATE
- IF OBJECT_ID(‘dbo.Orders’, ‘U’) IS NULL CREATE TABLE dbo.Orders (…), the pattern for permanent tables
- Rename the constraint in the new CREATE TABLE statement instead of reusing the old name
- MERGE for upsert logic instead of a CREATE-then-INSERT pattern when the goal is idempotent seed data
IF EXISTS syntax was added to SQL Server specifically to make these guards a one-liner instead of a query-then-branch. Use it at the top of any script that might run more than once against the same database, temp tables and permanent tables alike.
Postgres and MySQL Equivalents
Postgres raises relation already exists (SQLSTATE 42P07) for the same underlying causes, and CREATE TABLE IF NOT EXISTS is the direct equivalent guard. MySQL raises error 1050, Table already exists, with the same IF NOT EXISTS syntax available.
The pattern is consistent across all three: a re-run script or a name collision produces a database-specific error with the same shape, and the fix is always some form of check-before-create rather than assuming the database starts empty every time.
How this fits the rest of the stack
SQL Server error 2714 is not a database problem so much as a script that assumed it would only run once. Postgres and MySQL fail the same way for the same reason, and a managed instance does not change that, the guard belongs in the migration. What it does change is backups: a managed Postgres or MySQL instance with backups taken automatically makes recovering from a bad migration a restore instead of a rebuild. What that costs alongside the application running the migrations is on the RunxBuild hosting calculator.
Useful related references:
- SQL Error 18456: Login Failed, and the State Number That Tells You Why
- PostgreSQL CREATE DATABASE IF NOT EXISTS: The Workaround Postgres Does Not Have
- MySQL Error 1045: Access Denied, and the Four Things It Actually Means
- Databases on RunxBuild
FAQ
How do I fix there is already an object named in SQL Server?
Check whether the object already exists with SELECT OBJECT_ID(‘name’, ‘type’) before creating it, or wrap the CREATE statement in an IF OBJECT_ID(…) IS NULL guard. For temp tables specifically, DROP TABLE IF EXISTS immediately before the CREATE TABLE handles the most common case: a script re-running within the same session.
Why does my temp table already exist error keep happening?
A local temp table stays alive for the whole session, not just the batch that created it. If a script runs multiple batches separated by GO and an earlier batch already created the temp table, a later CREATE for the same name collides with the still-live table from earlier in the same session.
What is SQL Server error 2714?
The message SQL Server raises when a CREATE statement names a table, temp table, index, or constraint that already exists in the relevant scope. It is a naming collision, not data corruption, caused by a script re-run, a leftover temp table in the same session, or a constraint name reused across tables.
What is the Postgres equivalent of there is already an object named in the database?
Postgres raises relation already exists, SQLSTATE 42P07, for the same class of collision. CREATE TABLE IF NOT EXISTS is the direct equivalent of SQL Server’s IF OBJECT_ID guard, avoiding the error when a script might run against a database that already has the object.
What is the MySQL equivalent of this error?
MySQL error 1050, Table already exists, covers the same situation. CREATE TABLE IF NOT EXISTS works the same way in MySQL as in Postgres, and is the standard guard for a script or migration that might run more than once against the same schema.