Source Control tools for Visual Studio 2010 and SQL Server 2008 scripts and database updates?

Question

We are currently using Visual Studio 2010 and SQL Server 2008 R2 - developing intranet ASP.NET applications that use (several) SQL Server databases.

We have been storing

Answer 1

One additional factor or criteria you may want to consider is where you and your team are most comfortable writing your scripts \ stored procedures, etc.

We've evaluated Visual Studio Team Database Edition (or whatever it is currently called these days) in the past and came to the unfortunate conclusion that we just were not comfortable and happy writing SQL from within Visual Studio. We're much more productive as a team writing SQL using SSMS. You of course might find the opposite to be true.

We're also in the middle of evaluating Red-Gate's SQL Source Control tool. The biggest plus for us is that it works within SSMS and is relatively frictionless. For whatever reason, their model maps a bit better to how we tend to do SQL development work.

Regarding deployment, both products appear to skew slightly more towards development work where you are deploying changes to a database that is on your servers. From an ISV standpoint this makes it a bit more challenging to generate deployment scripts to be executed on a database outside of you environment (e.g. database hosted on a client's server).

For that reason, I personally like the approach Microsoft has taken where you can generate a schema file which describes the schema of the database. I'm probably leaving something out, but I recall that this schema file is what is used to generate the scripts to update a target database. The beauty of this solution is that the change scripts could be different depending upon the state of the target database.

Unfortunately, if you don't have "DBPro" available (again, think client site for a moment) you're left with using VSDBCMD to generate the change scripts from the schema file. While this works, it would be nice if Microsoft exposed an API for VSDBCMD so one could create a GUI to make it easier for non-developer types to execute rather than having to use a command line tool.

It's difficult to imagine that VS Team Database Edition won't gain additional features in the future, so betting on MS probably isn't really a gamble assuming of course you can live with the present shortcomings of the tool.