Hi Terry,

Don't get me wrong - your process isn't bad (sorry if I came across badly back there) - it's just not as optimal as it could be and, in fact, we aren't very far apart in most of our thinking.  Perhaps a little history of where we came from might help...

<shimmering effect> We started out writing DB Ghost because we had virtually the exact same process that you use and, althought we were just five guys sitting in the same cubicle, we still managed to create problems when moving to the QA environment such as re-using primary key values for static data, overwriting each others logic changes and writing new code against columns that had been removed by someone else.

We said "we didn't have these problems with release 1.0" why do we get them now?  The answer, of course, is that in R1 we just worked on the create scripts and then threw away & rebuilt the database whenever we did a release.  So, we mused, all we needed was a black box that can just look at our create scripts, automatically work out what is different, and then make those changes to the target database without losing any data. We had some full-and-frank discussions over whether it was possible - some toys were thrown, harsh words were spoken and some were even sent to bed early.  However we decided to write the "black box" and that's where DB Ghost came from (actually there was nearly a punch up over the name as well so maybe some counselling is in order ) </shimmering effect>

The custom scripts feature (before and after sync) is there so that any data migrations etc. (i.e. things that require semantic knowledge) can be slotted in.

Generally speaking the developers all work in their "wild west" sandbox databases and when they're ready, they check in their changes, backup the sandbox database and then use DB Ghost to update their sandbox database from the latest set of CREATE scripts from source control.  Better yet, if the scripts are extracted from a baseline/labelled set then you have a known point to work from in source control to answer questions like "what has been checked in since I last synched my database"?  As a purist a would suggest simply rebuilding the sandbox database from the scripts and then re-populating the data to avoid those annoying issues you get with corrupted data giving phantom failures during testing.

Another subtle benefit is that DB Ghost not only adds new objects and updates existing ones but it also removes anything that isn't in the source.  Thus it tidies up your local database whereupon you can do a last run through unit testing to absolutely make sure nothing was missed from the check-in...