SQLCompare aborts comparing process

noobix

Using SQLCompare I have exported our production DB to a script folder (baseline scripts).

After that I made some schema changes and tried to compare the changes against the original scripts.
SQLCompare aborts the process with the info message: "A duplicate object name (security.UserData)".

Therefore I was not able to compare/sync. the changes.

What am I supposed to do now to sync. and update my scripts?

Regards,
Tino

Michelle T

The usual cause of that error message is that SQL Compare and your database are using different case sensitivity settings. Please check your case sensitivity settings (the scripts take their case sensitivity from the collation you select on the database properties pane, and there is also an option to force case sensitivity which you could try turning on).

If that isn't the case, is the script folder reading in when compared to itself? Are you certain that the script folder hasn't had any changes since the original export (I've previously seen this problem where someone has accidentally managed to make a copy of one of the files in the folder structure)?

Other than those two things, I'm not sure what to suggest without seeing the scripts in question and a snapshot of the live database - if you can send these to michelle.taylor@red-gate.com that would greatly help with the troubleshooting, although I realise not everyone has the authorization to do this.

noobix

Hi Michelle,

I don't think I'm using different case sensitivity settings, I exported the DB as it is: SQL_General_Latin1_CI_AS.
After the export to the script folder the XML file there contains the same case sensitivity setting.
Is that as it's supposed to be, isn't it?

The script folder cannot even be compared to itself every time I try the message "A duplicate object..." pops up.

I'm quite confused right now and don't know what's going on with this tool.
We just cannot put this baseline script folder under source control due to nobody would then be able to sync. against it.
We definitely need these baseline scripts to continue our DB development process.

Unfortunately I can't send you the scripts due to I'm not allowed to.

Maybe you have other suggestions for me what to do?

Regards,
Tino

Michelle T

It sounds like what has happened is that somewhere in the scripts folder one of the objects has got duplicated (or one of the object names is incorrect and now clashes with another object name). This might be because we've made a mistake exporting the scripts from the live database (e.g. by writing out an object more than once or picking up the wrong name for an object), or it might be because one of the files in the script folder structure has been accidentally copied (or modified) after the initial export.

It's also possible, although unlikely, that this is some case in SQL Server where two object names can be the same, but we have made an incorrect assumption that they cannot be the same.

You should be able to fix it by finding the duplicate object (or object name) in the script folder structure and changing / getting rid of one copy.

If it persists (i.e. new script folders created from the database also suffer from this problem), any information you can provide on the nature of the object which is being duplicated and the objects that refer to it would be very helpful (ideally you'd send us a snapshot of a database which suffers from the problem when saved to scripts, but any information could be useful in tracking down the problem).

noobix

There are no duplicate files in the folder structure.
I didn't make any copies of the files there I didn't even touch them.

Maybe this is an application bug or maybe I'm doing something wrong,
right know I don't know what else to try.

As I said I'm not allowed to send you a DB snapshot.

Could you please provide me with an accurate step-by-step guide what to do create some baseline scripts of an production DB and use them in the development process? What I've been trying to do in the last days was following the steps you guys explained in the document describing the various DB development techniques. We finally decided to go for method #2 (subversion edit-commit style).