What are the challenges you face when working across database platforms? Take the survey

Script folder changes not being recognized

VerifexVerifex Posts: 10
edited May 5, 2008 6:42PM in SQL Compare Previous Versions
I just discovered the SQL Compare ability to compare against a scripts folder (I can't believe I missed this awesome feature!). And I've been using it for a week or two now pretty successfully. Now I just found some problem that I can't figure out. The directory containing all the scripts has a table definition in it that was different from the database table definition, so I had SQL Compare change the file and do a comparison following the change.

Much to my surprise though, SQL Compare shows that this file hasn't changed, even though when I edit the file in another editor it HAS changed. SQL Compare acts like it is working with a cached copy of the file itself somewhere. I'm not sure how or where this file is getting read, because I can't find the old SQL file that SQL compare is showing in it's little comparison screen.

Any help?

The SQL comparison is showing these changes:
[ColumnName] [bit] NOT NULL CONSTRAINT [DF__TableName__SPEOw__1955C986] DEFAULT (0),

[ColumnName] [bit] NOT NULL CONSTRAINT [DF__TableName__SPEOw__1955C986] DEFAULT ((0)),

Yes, thats right, the only difference is the extra parenthesis, however the script file in the directory I'm looking at shows the line exactly as the database says. Is this a bug?

Also, the extended properties on the table in the database are identical to the table definition the disk, however, SQL Compare is showing the old extended properties before the change.

I checked the database directory for other places where the table definition might be duplicated, but I didn't find anything. Has anyone else experienced this?

I'm using SQL Compare Pro v



  • Options
    Brian DonahueBrian Donahue Posts: 6,590 Bronze 1

    SQL Compare ignores extra sets of paranthesis because SQL Server 2005 started padding them with an extra set whenever DDL is run on the server. This had caused us some big problems with reports of 'false differences' when the program was made SQL Server 2005 compatible, so now they are ignored. As far as I'm aware, the extra characters don't make any functional difference.

    I hope this explains it.
Sign In or Register to comment.