“We run teams of between 2 – 5 developers on different projects. They are generally distributed, many working from home offices.

Before SQL Source Control

Because development involved remote working , each staff member has their own machine with a copy of Visual Studio 2010 and SQL Server 2008 installed locally to work with.  We were able to easily sync up the code base via source control (SVN or more recently we’ve moved to TFS2010). But keeping the database in sync had always been a painful struggle. Depending on the project and team size we tended to use, before SQL Source Control, one of the following methods:

1. Manual backup and restores. Whereby a database .bak was generated periodically and e-mail around the team to do a restore and make sure everyone was up to date. Problematic as only one developer can make changes to the DB before it needs to be re-distributed.
2. SQL create scripts via the ‘Create Scripts’ option in SQL Management Studio (formally the SQL Database publishing wizard). Similar to manual backup’s we would generate all the SQL scripts to drop and rebuild the database including data, which would then be distributed.
3. One of our developers rolled his own DB sync tool which could do a DB schema compare and then alter the database accordingly to match. This was time consuming developing our own solution, and really only worked in a situation where both the source and target DB could be accessed at the same time (unlikely).
4. More recently we started to use Database projects within Visual Studio, which would also allow a schema compare and update – but this too was clunky and tended to be quite fragile when substantial changes had to be made.

What prompted us to look for source control for SQL Server development was the simple need to find an easier way to keep our database structure in sync across the team – we iterate quite rapidly using an agile development methodology, so our data model alters frequently.

We’d heard about SQL Source Control when one of my development team brought it to my attention – and being familiar with the quality of Red Gate products I immediately looked at it.

With SQL Source Control

The reaction of the SQL Developers was overwhelmingly positive, as it solves a major pain point for us all, and It’s now much less hassle to keep our database schemas in sync, so that is a huge time saving. With the tool, we were able to eliminate many painful manual schema update procedures and move everything into our TFS source control.

I highly recommend SQL Source Control to anyone who is doing software development around SQL Server. It takes the pain away from an otherwise tedious process of syncing database schemas across a team, and lets us focus on what we do best – developing great software. It integrates seamlessly into the SQL Management Studio interface, and works hassle free with existing source control systems.”

“Before we got SQL Source Control, we used a home Grown DB Upgrade Tool and development convention / methodology. It was able to accomplish all of the functionality of SQL Source Control, but it took a lot of time that I could ill afford. The trouble was the time it took to teach new Developers how to use the DB Upgrade tool and instructing, or enforcing, development Conventions. We first heard about SQL Source Control by reading a Blog Entry from another developer.

The reaction of the developers to SQL Source Control was ‘WHOO HOO!!’. We all saved a lot of time that had previously been spent in making modifications to database schema and getting changes pushed out to other developers.

I’m surprised to find myself saying I would recommend a Version 1.0 of any product.  While I am sure there are great improvements to come in future versions, the current version / build immediately brings database schema coordination between developers, saving time, and frustration.”