marianf

When I do a schema compare, my default values cause a false positive difference because of default values.

Say the default is an integer n, then I see "(n)" in the source, "((n))" in the target.

I followed suggestions in prior posts and set ignore constraing and index names on.

Also I told it to be case insensitive.

But it is still happening.

What to do




Re: Visual Studio Team System - Database Professionals Default values in schema compare

Gert Drapers - MSFT

Did you restart VS after you changed the option, I am not certain this takes effect immediately in an open session

-GertD





Re: Visual Studio Team System - Database Professionals Default values in schema compare

marianf

No I didn't. I will try it Monday morning.

Thanks,

Marian.






Re: Visual Studio Team System - Database Professionals Default values in schema compare

StevenPo - MSFT

Marian -

Are you still blocked by this issue, or did Gert's suggestion get you unblocked

thanks,






Re: Visual Studio Team System - Database Professionals Default values in schema compare

marianf

It did solve this issue. I am now dealing with two other similar issues.

Some of the same tables still show up as different where they are not really different.

My project was created from a SQL 2000 database.

The source of my schema compare is my project. The target is the SQL 2000 database.

CREATE TRIGGER gtrTreeItemUpdate

ON dbo.[tbTreeItem]

FOR Update

AS

INSERT INTO fly_audit.dbo.[tbTreeItem]

SELECT 'UPDATE',

GetDate(),

SYSTEM_USER,

'ACTIVE',

ID,

ItemName,

Code,

Description

FROM Inserted

GO

GO

The second GO is in the target only.

There is a GO statement in the trigger which seems to cause this.

When I manually remove GO statement from the target using SSMS I still see it in my compare, now because of automatically generated brackets:

Since I have multiple tables with the same problem, I am showing this for a different table than the one above - because I removed the GO from this I couldn't use it any more in the example above.

source:

CREATE TRIGGER gtrTreeStructureDelete

ON dbo.[tbTreeStructure]

target:

CREATE TRIGGER [dbo].[gtrTreeStructureDelete]

ON [dbo].[tbTreeStructure]

I haven't done my research on this yet - just giving you the feedback you asked for.

Marian.






Re: Visual Studio Team System - Database Professionals Default values in schema compare

StevenPo - MSFT

Feedback is always helpful. I'll loop in one of the developers to see if we can get an explanation for the new issue that you're seeing.






Re: Visual Studio Team System - Database Professionals Default values in schema compare

Chuck Weininger - MSFT

The square brackets are not automatically generated on the name of a trigger, so I'm curious as to why they aren't there in your project. It almost seems like they were removed from the trigger in your project after it was imported.

I don't know why the GO would be causing problems. Maybe when the trigger was imported into the project, the extra was stripped off for some reason. Other than going through each difference and fixing the problem, I'm not sure there is anything you can do. If you figure out how the project and database got into this state, I'd be interested at taking a look to see if there is a way we could have prevented it.

Thanks for you feedback,






Re: Visual Studio Team System - Database Professionals Default values in schema compare

marianf

My theory is also that the import stripped off a Go.

My triggers are all very similar and we do not write them.

Instead we wrote a little vb program that generates them.

I imagine the vb program put a "Go" in the trigger and the database import took it out.

I can see the Go in the trigger definition on the target and if I remove it manually, then the compare sees source and target as the same (One "Go")

I think the brackets are my problem, not yours.

I have two servers that are supposed to be identical. One is production and was used to import my schema from.

The other is development and is supposed to be identical. However, it differs from production in these brackets, I do not know how that happened.

When I compare to production, the Go issue shows up, but the brackets are identical. So that is good.

When I compare to development, the Go issue shows up, plus I have a bracket difference. I wish I could set an option to ignore the brackets, but I have the possibility of just updating the development database and be done with it.

Thanks for responding,

Marian.