Add preemptive error checking.
One of our challenges is that it is too easy to break the get latest functionality. If a developer renames a column but doesn't rename all references (because he forgot to use Smart Rename) he is essentially breaking the database build. If I use Continues Integration to build the latest SQL changes, I have no bullet-proof way of ensuring that my database compiles at all time. I would like to ask Redgate to not allow a check-in which will break the build. I imagine that all that needs to be done is to ensure that first generation dependencies don't have errors. It would be nice if this is an option that can be turn on or off.

using SQL Source Control 3 and SQL Compare 10.2
i renamed a table from X to Y. as others noted, SQL source control sees the change as drop X and create Y. i want to create a migration script but that would take too long as the script has to drop relations with other tables, related SPROCS and that would take too long to write and debug.

on the other side, SQL Compare 10.2 knows how to handle a rename of a table. all i have to do is map the tables and i get the table renamed with a few clicks.

my suggestion: allow on commit on sql source control to add rename hints that sql compare can use. for example on the commit i will define a migration script as a rename of X to Y. that in turn will cause SQL compare to see this hint and automatically set up a rename of table X to Y

This was already discussed on the Red Gate forums in 2007:
http://www.red-gate.com/messageboard/viewtopic.php?t=5875

As of SQL Data Compare 9.1.0.365, the problem still exists.

From the forum thread:

"""
I find that very often, a column containing floating point numbers will show as different [in SQL Data Compare], even though visual inspection of the results [in SQL Server Management Studio] shows that it is the same.
"""

It's difficult to know if the data in the float column has actually changed, or if it's just SQL Data Compare making an innacurate comparison.

It reduces my confidence that the data has been synchronized correctly.

I'd like to see migration scripts support for PlasticSCM. Why isn't something that is written as a "plugin"? Plastic isn't supported out of the box, but it's a simple enough matter to make a config file for it. Why can't the same be done for migrations? Allow the end user to create a config file (perhaps requiring the use of regular expressions for history parsing) or some other such mechanism. It seems like this should be a relatively straightforward thing to be able to do (it would also allow the customers to create the support for any SCM system they use).

SQL Source Control increments a Revision number after each change. Does this imply that I am required to apply all changes up to a given Revision in a second database? I really want to apply only selected changes, and in my own order.

RELATED: If I select Revision 10 to apply to my database, and then select Revision 7, have I effectively removed changes for Revision 8, 9 and 10?

Note that I am most concerned about DATA in these cases. The schema for this particular project is mostly stable. I'm just trying to keep track of data rows that determine program functionality (data-driven application).

Using SSC 3.0.11.3531
Dedicated development model

1. We finally get a nice little notification that Commit Tab has been updated. (Kudos for finally doing something in the background and letting users know they have to take action on something)
2. Click on the notification to open the Commit Tab
3. Wait for SSC to determine latest version and work out whats changed.
4. Select my items and say commit
5. Wait for SSC to once again determine the latest version and work out whats changed and commit my selected changes to TFS.

Surely
a) You already know what items are changed in order to show notification, so you shouldn't need to do it again.
and b) at least once I've selected the changes to commit, you don't need to once more determine whats changed again?

My poor little disk in my desktop machine is being thrashed to death.

Cheers
Phil