I hope I'm not hijacking this thread but I feel the discussion is a good one.

Malcolm (sorry I misspelled it before) the solution I talked about does use a "schema.sql" file as the master copy of the database schema (the same approach your product seems to take), but if you are not storing the diffs, how do I as a remote dev, get your changes applied to my sandbox database without dropping the whole thing.

The approach I talked about uses both, the full schema file to represent the 'official' version and diff files that can be applied by team members to update their database environment.

You bring up a good point and one that I didn't consider was to use the SCM to lock the 'schema.sql' since this resource is serving as the official version. If the patch diff generation process uses an exclusive lock of the schema.sql file to ensure that only diff is being generated at a time then this is much better than the 'hey i'm about to generate diff 15' approach that I mentioned in my first response.

Now I highly recommend in any sandbox approach that devs don't get married to their copy of the database and that they periodically wipe it and recreate it from the official scripts and that any data they are they are using and any tables that they are working on that are not part of the official schema, they should have their own scripts to create the objects/data until that feature is ready to be merged into the official database schema.

I see your product does allow pre/post scripts to run so I see how you could batch this up to use ant/nant/msbuild to use any SCM to lock the schema.sql file even if you are not using VSS.