Terry,

How do you reconcile the full schema "official version" from what is represented by the developer's change scripts?  This is a necessary step in any approach that tries to use two versions of the truth as the two will always diverge over time.

What normally happens (in my experience of project that use the techniques you describe) is that the "official version" simply gets out of date and so the developers end up copying each others sandbox databases, because *they work*, and the official version *doesn't* so the official version ends up being shelved or marginalized.

Basically, in any process, you should only ever have one version of the truth - that's what we have for every other type of source code and that is what we should have for SQL code as well. 

Any process that relies on multiple diff scripts is doomed to be resource intensive and error prone.  Why would anyone risk hand rolling an inefficient process against their company's most important asset (the database) when there are inexpensive tools on the market (such as DB Ghost and now SQL Compare 6) that are proven and make everything easy and rock solid?