Comments
Sort by recent activity
Andras wrote:
Are you using a user defined type?
No, in my database we do not use UDT. However we use bit and int a lot, and I am getting this problem on those fields.
Do I understand correct, that a dot-release should improve the problem, and how do I go about getting a notification when it is made available.
Thanks,
Thies. / comments
Andras wrote:
Are you using a user defined type?
No, in my database we do not use UDT. However we use bit and int a lot, and I am getting this problem on those fields.
Do I understand correct,...
Neil Davidson wrote:
Can you go to the help->about box and let us know what version of SQL Compare you're using please.
I was running 3.x of SQL Compare. I am now running 5.0.0.1622.
I have still not found a workaround comparing; SQL 2000::DEFAULT (0) with SQL2005::DEFUALT((0))
BTW; I like the little game you guys added in the About box - do I get a prize of I put all the pieces in the right place, and what is the Lama doing in the picture?
- Thies. / comments
Neil Davidson wrote:
Can you go to the help->about box and let us know what version of SQL Compare you're using please.
I was running 3.x of SQL Compare. I am now running 5.0.0.1622.
I have st...
Brian Donahue wrote:
You may want to have a look at this blog: http://blogs.red-gate.com/blogs/andras/
This contains some information about how we have adjusted SQL Compare to cope with SQL Server 2005's requirement for doubling-up the partentesis.
I read through this, but am not quite sure if it makes things clearer to me. I need a way to compare an SQL 2000 database with an SQL 2005 database, and after syncronize them the two, having SQL Compare tell me there are no differences between the two.
With the way things are now between 2000 and 2005, it compares SQL 2000s: DEFAULT (0) with SQL 2005s: DEFAULT ((0)) and says they are different. Fine, lets sync these differences and recompare. SQL Compare suggests chaning the SQL 2005s DEFAULT ((0)) with DEFAULT (0) - but when this is executed on the SQL 2005 side, it changes again to DEFAULT ((0)), as expected. If I could get the DEFAULTs used in 2000 and 2005 to be viewed as the same, I would be happy, as that would be a once off - I am happy doing changes either in the SQL 2000 database or the SQL 2005 database.
Problem: In SQL 2005 I cannot make DEFAULT (0) work. In SQL 2000 I cannot make DEFAULT ((0)) work.
My main issue is SQL Compare saying these are different, is it makes me have to add a manual (read: error prone) process of checking the defaults in a seperate task (disabling DEFAULT checking in SQL Compare).
I understand that this is not SQL Compare that has changed, but some other product. I would however love if SQL Compare where to handle this case.
I love SQL Compare/SQL Data Compare - my job would not be as fun without such tools. / comments
Brian Donahue wrote:
You may want to have a look at this blog:http://blogs.red-gate.com/blogs/andras/
This contains some information about how we have adjusted SQL Compare to cope with SQL Serve...
vfursov wrote:
Brian Donahue wrote:
Hello,
Yes, I see. Currently you can only see what the resulting synchronization script looks like if you click the synchronize button and go through the synchronization wizard. And to just see the script for one object, you need to de-select everything and just select the object you're interested in.
In SQL Compare 3.1.7.218 that I was using before upgrading to 5.0 this was possible. For each difference I could select a Tab 'Sync SQL 1' or 'Sync SQL 2' on the difference that would give the SQL to use for the single difference shown.
I used this a lot, and after reading this post I checked SQL Compare 5.0 and was *very* supprised not to see this feature there. I used this all the time, as I use SQL Compare to build upgrade scripts between versions of our product and need to think about every change required. Therefore I do one change at a time, and do not use the complete syncronization script.
Maybe insight in to why the feature was dropped, would help me understand how I should be using the product better?
Thank you,
Thies. / comments
vfursov wrote:
Brian Donahue wrote:
Hello,
Yes, I see. Currently you can only see what the resulting synchronization script looks like if you click the synchronize button and go through the s...
rbennet8 wrote:
In the older versions of sql compare and data compare you could set the options one time and go about using them. With the new version, you have to set them for every project and it appears if you edit the project, they get set back to the original defaults. Is there a way to set the option defaults? I don't think it is an improvement, to always set the options when comparing a new database. [image]
I would have to agree here. I like the way I can see my older projects, but I do not like having to reset my options everytime I build a new project.
Jonathan, you describe that new projects will use 'default' options. How can I change these default being used so I no longer have to remember re-setting my prefered options? / comments
rbennet8 wrote:
In the older versions of sql compare and data compare you could set the options one time and go about using them. With the new version, you have to set them for every project and...