A duplicate definition was found for the table

[BrandonGalderisi]

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.

[simon.jackson]

Hi,

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.

[BrandonGalderisi]

So if after I had SQL Source Control build my base project, I created an upgrade folder in which I housed my manually created version upgrade scripts, that would be the issue.

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.

[sherr]

It's currently not possible to ignore a certain folder within SQL Source Control.

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

[BrandonGalderisi]

Thanks. I did move the upgrade folder to a different location outside of source control. For the time being, I am happy managing the upgrade file myself but maybe that will change. I know all about compare and have found it useful for finding things the developers try to sneak in.