RedGate SQL Source Control is a Management Studio add-in that allows you to seamlessly (hopefully...) connect your existing source control system to SQL Server. It is advertised as doing all the typical stuff you'd expect:
- Source control schemas and data within SSMS
- Connect databases to TFS, SVN, Sourcegear Vault, Vault Pro, Mercurial, Perforce, Git, Bazaar, and any source control system with a capable command line
- Work with shared development databases, or individual copies
- Track changes to follow who changed what, when, and why
- Keep teams in sync with easy access to the latest database version
- View database development history for easy retrieval of specific versions
The one thing I couldn't find currently supported is a Visual SourceSafe connection. It seems to be available in an "Early Access" version that you can sign up for, and since VSS has command-line capabilities I'm guessing it could be made to work, but SQL Source Control needs a custom config file created (which I can't seem to find specific instructions on). Yes, VSS represents everything evil about source control, and Microsoft is pulling the support plug next year, but there are still loads of corporate environments using it.
Installation is simple - just go to the Redgate site and download a 28-day free trial. You'll actually be getting a trial version of their complete SQL ToolBelt, but you can choose to only install SQL Source Control if you like.
Once SQL Source Control is installed, you'll need to link your database to source control. Open SQL Server management Studio and you should see a new SQL Source Control tab like this:
Click on the Link database to source control... link, and you'll get this:
Here you'll choose your source control system and configure the necessary folders or URL. I didn't want to connect to an existing source control system, so I chose Just Evaluating and created a local Subversion repository.
Finally, you'll have to choose your development model - either Dedicated database or Shared database. For more information on the differences, see this article, but basically you're choosing whether each developer has their own copy of the database, or all developers work on a central copy of the database. Since I'm going to be the only one testing this, I suppose it doesn't matter, but I went with Dedicated database.
After you've clinked Link, your database will be linked to source control. You'll notice that the icons in Object Explorer change to show that the database is linked:
Now you'll need to do your initial commit and save the initial copy of everything to source control. Click the Commit Changes tab and you should see a list of all the database objects that will be committed:
Go ahead and hit the Commit button; the system will churn for a minute then display a completion message:
At this point we're ready to start making changes and see what happens. I opened a stored procedure by right-clicking it and choosing Modify, then made a simple change to a varchar length and clicked Execute. Going back to the SQL Source Control tab, and clicking the Commit Changes tab (if necessary), I've got one item listed with a summary of the changes:
I added a comment and committed, and everything seemed to work fine. I then changed the proc back the way it was and committed the changes. Now, right-clicking on that same stored proc allows me to select Show History and view the different versions, along with changes to each:
Had I been working in a multi-user environment, there could have been conflicts in the object I was trying to commit; in that you're given the option to Keep mine or Take theirs - merging is not currently supported.
One thing I noticed is that I can't simply right-click on one of these versions and roll back to it - I'm given the prompt "Update to this version with SQL Compare Pro...", but when actually clicking that I'm unable to do anything since I don't have this tool installed. See this page for some info on getting a specific version using this tool. If you don't don't have SQL Compare Pro installed, then your work-around for rolling back is copying and pasting the SQL code from the History window.
You can also link static data (database tables that almost never change, such as one containing US states) to source control - just right-click on the table and choose Other SQL Source Control Tasks -> Link / Unlink Static Data.
Since I was testing this on a single machine, as a single user, I can't really test getting the latest version from source control (at least no very easily). You can read about the process on Redgate's site, but it appears pretty straightforward - either go to the Get Latest tab and select the objects you want to update, or right-click on a single object and select Get latest changes from source control.
Your able to deploy an entire database from source control to a server, but that also requires SQL Compare, so I didn't test it. Go here for some more info.
SQL Source Control is priced at $295 for a single-user license, dropping to $207 per user if bought in a 10-user license ($2065 total). It's also available as part of either Redgate's SQL Developer Bundle (starting at $1047/user) or SQL Toolbelt ($1397/user).
Don't forget, you'll also need SQL Compare Pro if you want to be able to roll back to previous versions. It runs $595 for a single user, and $417 per user in a 10-user license ($4165 total). It's also available in the SQL Toolbelt bundle (but not the SQL Developer Bundle).
SQL Source Control seems to do *most* everything I'd need, at a reasonable price if you're looking at a 10-user license. However, two things currently are deal-breakers for me, at least in my work environment:
- The need for SQL Compare Pro to automatically roll back to previous versions. I can't justify an additional ~$500 per user to my boss to be able to implement this, and I REALLY don't want to be forced to copy and paste...
- Lack of VSS support. Yes, we're *still* using it, but moving to another system is not a battle I'm going to win any time soon. Since this is in their Early Access program, I'm hoping future versions will have direct integration.
Also, merge capability would be nice, but I suppose I could live without it. If these two problems were solved I wouldn't hesitate to implement this in my department.
Disclaimer: I was offered a licensed copy of SQL Source Control for this review.