A duplicate definition was found for the table
BrandonGalderisi
Posts: 22
I am getting the following error:
A duplicate definition was found for the table [dbo].[XXXXXXXX]. Ensure that case sensitivity options are set correctly and all object creation scripts are valid. If the problem persists, contact our support.
This is a new database that I just created on my local box, connected to a new SVN project folder that I just created on the server.
Any help would be appreciated.
A duplicate definition was found for the table [dbo].[XXXXXXXX]. Ensure that case sensitivity options are set correctly and all object creation scripts are valid. If the problem persists, contact our support.
This is a new database that I just created on my local box, connected to a new SVN project folder that I just created on the server.
Any help would be appreciated.
Comments
Thanks for reporting the issue. The error indicates that there are two files under the directory the database is linked to which contain "Create table [dbo].[XXXXXXX]". One case this can happen is where you link to SomeFolder, and then copy it into itself, so you end up with
SomeFolder
SomeFolder\Tables
SomeFolder\Tables\dbo.XXXXXX.sql
SomeFolder\OldVersion
SomeFolder\OldVersion\Tables
SomeFolder\OldVersion\Tables\dbo.XXXXXX.sql
Is it likely you have two copies of the create table file in source control? If so, can you see why? If you could email me a zip of the folder from source control ( to my username @red-gate.com) I should be able to see more of what's going on.
Because when we have a DB release, not only do we have the base file with the create table statements, but if we add a new table, we build and run a patch file which contains alter tables, create tables, and create procedures.
Is it possible to make an option to ignore a certain folder? It would obviously work best for my patch scripts to be in the same folder as my new deploy scripts.
Is it possible to move your "upgrade" folder to a higher level that is not within the SQL Source Control directory? Maybe you could have a structure like:
- Database - high level root folder
-- SchemaChanges - Point SQL Source Control here
-- Upgrade - Use for your patch files
Have you tried using SQL Compare to deploy your changes? You can use SQL Compare to compare a scripts folder (if you get a version using your source control system) or your development database to a target database (e.g., Test/QA). SQL Compare will show you all the differences. You can then automatically generate a syncrhonization script, which will create all the ALTER statements for you. It will take care of dependencies and order as well. This can be ran directly on the target db or it can generate a script that you can open in SSMS and review yourself before executing.
I hope this helps!
Stephanie M. Herr :-)
SQL Source Control Project Manager
Stephanie M. Herr :-)
Product Manager Database DevOps