Comments
Sort by recent activity
I'm afraid there isn't currently a way to automatically initialize newly added fields with default values. It's a feature we've been considering adding in future releases, and I'll add this thread to the feature request.
Currently the obvious workaround is to add a default constraint to the field in the source database, but we understand that isn't the best solution if you don't want the field to have a default after the synchronization is complete.
You can also save the synchronization script / ask Compare to load it in Query Analyzer or Management Studio and then edit the script by hand to have a default constraint added and then dropped from the column. / comments
I'm afraid there isn't currently a way to automatically initialize newly added fields with default values. It's a feature we've been considering adding in future releases, and I'll add this thread ...
It looks like you might have found a problem with our database connection logic in v6. I'll need a little more information to pin it down...
Do you get any kind of error message from v6, or does it just wait at the Fetching... stage for longer than v5 takes to populate the database list?
Have you tried making a new project in v6 to connect to the database in question? If this doesn't work, can you try referring to the remote server by IP address and see if this works?
Are you using SQL Authentication or Windows Authentication?
Is the remote server accessible via named pipes and TCP/IP, or just one or the other? Are there any firewalls in place requiring a different port to be used for TCP/IP?
If you could send us the project file (to michelle.taylor@red-gate.com) as well, that might help. / comments
It looks like you might have found a problem with our database connection logic in v6. I'll need a little more information to pin it down...
Do you get any kind of error message from v6, or does it...
I tried putting these scripts in two script folders to see if I could generate the difference, but Compare correctly reported them as equal to each other. I ran the create statements into databases and managed to get a 2005 database with ((0)) and a 2000 database with (0), and the main grid still reports them as equal.
I strongly suspect there is some difference between the tables in the live database that we are not displaying clearly enough - something that isn't visible at the level of a creation script which is causing Compare to decide that the tables are different.
If you could send database backups (or SQL Compare schema snapshots, if you can't send out actual backups) of the affected databases to michelle.taylor@red-gate.com I can take a closer look at the actual objects and perhaps figure out what's different about those tables.
(If you aren't even allowed to send me schema snapshots, take a look at / send me the SQL script shown in the SQL Differences viewer when you press the SQL button - if it has any statements between the 'BEGIN TRANSACTION' and the line with 'ROLLBACK TRANSACTION', it might let me track down what's going on here.) / comments
I tried putting these scripts in two script folders to see if I could generate the difference, but Compare correctly reported them as equal to each other. I ran the create statements into databases...
SQL Compare shouldn't be treating the two default constraints as different. They will show up on the SQL Differences pane as different, because they are textually different (the Differences pane only does a textual comparison for performance reasons), but the table shouldn't show up different in the main grid for this reason.
It looks like SQL Compare has found some other difference in your table which it is having trouble synchronizing.
Do you have encrypted triggers on one or both tables? If a trigger is encrypted (in 2005 where we can't break the encryption) SQL Compare can't tell if it's equal or not, so it assumes that it is different - and as it can't read the trigger on either side, it can't synchronize them, so the tables will remain different.
If encrypted triggers aren't the problem, could you post (or send me - michelle.taylor@red-gate.com) the table SQL on each side and the synchronization SQL that you get from pressing the 'View object synchronization script' button on the SQL Differences pane? Hopefully I'll be able to work out from these what the difference that SQL Compare is finding is, and why it isn't synchronizing properly. / comments
SQL Compare shouldn't be treating the two default constraints as different. They will show up on the SQL Differences pane as different, because they are textually different (the Differences pane on...
Thank you for your report - I've added it to our bug tracking database.
We know that there are a few issues around replication like this, and we're gradually working on them - I'm not sure when we'll get around to fixing this particular issue, but it's now in the queue. / comments
Thank you for your report - I've added it to our bug tracking database.
We know that there are a few issues around replication like this, and we're gradually working on them - I'm not sure when we'...
It sounds very much like the error you get when your download of an executable file doesn't finish, leaving you with a partial file. You might want to check that your file is 28.1MB long - if it's shorter then this is almost certainly the problem and I'm afraid you'll have to re-download the file. / comments
It sounds very much like the error you get when your download of an executable file doesn't finish, leaving you with a partial file. You might want to check that your file is 28.1MB long - if it's ...
Thank you very much for reporting this!
It's now in our bug tracking system and hopefully we'll get it fixed for 6.1.
Sorry for the inconvenience,
Michelle / comments
Thank you very much for reporting this!
It's now in our bug tracking system and hopefully we'll get it fixed for 6.1.
Sorry for the inconvenience,
Michelle
In the meantime, if you manually seperate the table and the trigger into seperate script files, then SQL Compare will try and update the seperate script files instead of combinding the two objects again. Occasionally (e.g. if you change the name of the trigger) it will put the trigger back in with the table, but most operations preserve the structure you've set up with them in different scripts. / comments
In the meantime, if you manually seperate the table and the trigger into seperate script files, then SQL Compare will try and update the seperate script files instead of combinding the two objects ...
This bug is fixed in the currently released version of Compare (6.2) - there is now an /allowIdenticalDatabases option (alias: /aid) for the command line which will produce a report instead of an error for identical databases. / comments
This bug is fixed in the currently released version of Compare (6.2) - there is now an /allowIdenticalDatabases option (alias: /aid) for the command line which will produce a report instead of an e...
I can see your problem:
Your target database is the live database.
If your target database is a live database, you should not attempt to pass a WriteToFileOptions object to work.BuildFromDifferences, whatever kind of database your source database is.
So:
work.BuildFromDifferences(MyDifferences, Options.Default, true, MyWriteToFileOptions);
should be:
work.BuildFromDifferences(MyDifferences, Options.Default, true);
Hope that helps. / comments
I can see your problem:
Your target database is the live database.
If your target database is a live database, you should not attempt to pass a WriteToFileOptions object to work.BuildFromDifference...