Case study from Phil Gale

"Our reaction was basically 'Whoohoo!'"

The developers at Red Jungle had tried everything. They just couldn't find a trouble–free way to keep their databases synchronized. When they heard about SQL Source Control, that changed.

The company develops web sites and web-based applications, with between two and five developers on each project. Generally, they work from home offices, on their own machines. The teams iterate quickly, so their data model changes frequently.

Given our remote working setup, keeping databases in sync had always been a painful struggle.

says Phil Gale, Red Jungle's managing partner and software development lead.

Before using SQL Source Control, we'd tried a whole bunch of things.

Sometimes we passed around manual backups, or SQL CREATE scripts, but that meant only one developer could work on the database before we had to issue updates again.

We tried Database projects in Visual Studio, but they were clunky, and rather fragile when we made substantial changes.

One of our developers eventually cooked–up his own sync tool. It was a time consuming project. We had to teach new developers how to use it, enforce certain conventions, and it only really worked when source and target could be accessed at once, which wasn't often.

It was Matthew Hintzen, Red Jungle's Systems Architect, who finally hit on SQL Source Control, after he came across it on a fellow developer's blog. Hintzen explains,

We'd settled for working with the home–brewed tool,

But SQL Source Control did everything that could do, without wasting time or causing frustration. Our reaction was basically 'Whoohoo!'

Integration with SSMS and TFS saved us a lot of hassle, but the major benefit has been the time its saved us making and pushing database changes. I'm not sure I could give that up again.

Gale adds,

With SQL Source Control we can focus on what we do best – developing great software.