Problem: SQL Compare tries to add existing column

seannerd

SQL Compare 10.0.0.181 tries to add an existing column because the default constraint has a different name

In the script, I get these lines:

PRINT N'Altering [dbo].[updates]'
GO
ALTER TABLE [dbo].[updates] ADD
[settings] [int] NOT NULL CONSTRAINT [DF_updates_settings] DEFAULT ((0)),
[settings_r] [int] NOT NULL CONSTRAINT [DF_updates_settings_r] DEFAULT ((0))

But those two columns exist. Here is the compare screen shot of the difference before the script was generated:

And, to add to it, after errors occur, it tries to drop the columns a few lines later presumably because it thought the script was adding them.

I think, what should have happened here is:

alter table updates drop constraint DF__updates__Setting__405B5365
alter table updates add constraint DF_updates_settings default ((0)) for settings

alter table updates drop constraint DF__updates__Setting__414F779E
alter table updates add constraint DF_updates_settings_r default ((0)) for settings_r

Is this a bug, or am I running this with a bogus setting?

Thanks.

- Sean

Brian Donahue

Without knowing the whole schema, it's hard to tell what's going on, but if you want to eliminate the possibility that SQL Compare is doing something because of the constraint names, you can eliminate that using the "ignore names of constraints and indexes" option.

seannerd

Yeah - I ended up using "ignore names" to get through it - though I sort of want the names. I can live without it.

I ran a test on a simple DB with one table, and SQL Compare did what I would expect, and dropped the original constraint, and re-added it with the new name.

So - I'm not sure what happened. But - I cannot mess with it anymore right now, unfortunately.

Thanks, Brian.

- Sean