Different objects?

Oleg

These objects are different in this version.
But they are equal

[deleted] [int] NOT NULL CONSTRAINT [DF_nodes_deleted] DEFAULT ((0)),...


[deleted] [int] NOT NULL CONSTRAINT [DF_nodes_deleted] DEFAULT (0),

Andras B

Oleg wrote:

These objects are different in this version.
But they are equal

[deleted] [int] NOT NULL CONSTRAINT [DF_nodes_deleted] DEFAULT ((0)),...


[deleted] [int] NOT NULL CONSTRAINT [DF_nodes_deleted] DEFAULT (0),

These objects we are detecting as equal (more information about this topic is on http://blogs.red-gate.com/blogs/andras/). The double parantheses around certain default values is an architectural flaw in SQL Server 2005, but we compensate for it and compare constraints at a semantic level (as much as possible ).

Regards,
Andras

Oleg

Thank you Andras.
Could you see my last message?
Is it true? non correct scripts?

Regards,
Oleg.

monty

Hi Andras,
According to the blog entry you mentioned in your last post on this topic, the comparing of the default values has been taken care of, however, I'm still getting differences being displayed in SQL Compare.

eg
Server1 (SQL Server Express 2005 (9.0.1399))
[ContractFactor] [float] NULL DEFAULT ((0.0))

Server 2 (SQL Server 8.0.194)
[ContractFactor] [float] NULL DEFAULT (0.0)

Is this just a problem that can't be solved, or is there a setting somewhere that does this (I can't seem to see one)??

thanks
Mark

Brian Donahue

Hello Monty,

I think that the situation has changed a bit since then. SQL Compare should compare the default values accurately -- it's the synchronization that's the problem. Because even though SQL Compare scripts a single paranthesis (), SQL Server will take this and pad it with parenthesis again(()). Then the next time you compare, this will show up as a difference again. I don't think we can help with this, at least right now. If we can do something in the future or come up with a workaround, I'll let you know.

Andras B

monty wrote:

Hi Andras,
According to the blog entry you mentioned in your last post on this topic, the comparing of the default values has been taken care of, however, I'm still getting differences being displayed in SQL Compare.

eg
Server1 (SQL Server Express 2005 (9.0.1399))
[ContractFactor] [float] NULL DEFAULT ((0.0))

Server 2 (SQL Server 8.0.194)
[ContractFactor] [float] NULL DEFAULT (0.0)

Is this just a problem that can't be solved, or is there a setting somewhere that does this (I can't seem to see one)??

thanks
Mark

Hi Mark,
Brian is right that these defaults cannot be reproduced the same way on a target database. This is a SQL Server limitation. And this is the reason why we compare them at semantic level. If this is the only difference between two tables we should mark them as being equal. Note, that in the bottom panel we display textual differences, so there the different rows are marked as different. I have created a table with the above column specification, and as expected the tables were marked equals, but the bottom panel (that shows the scripts) a textual difference is shown.
Please let me know if you are experiencing a different behaviour. I would also appreciate if you could tell me what non default options you are using.

Regards,
Andras

monty

Hi Andras,

My appologies. I was just getting the version number of the SQLCompare utility when I noticed that it was version 3.x. I must have downloaded the tools a day before the version 4 versions were released .

Version 4 works as expected, the tables are now considered to be identical.

thanks
Mark