Hi Steve,

For what its worth I think your article was good.   I really like the idea of having rollback script/release, allthough for me (and Im sure most people), the headaches of trying to reliably produce it from our source code would be difficult with multiple development streams on the go, at the same time, with varying release to production schedules, hot fixes...

I think the only way to generate the rollback reliably is for the deployment tool/script/whatever, to detect/know the code being released and automaticaly generated the rollback script/release at the time of deployment.   Yeah I know..not trivial!

Sorry I cant provide some insightfull and novell approach, except that i agree with most of the points in your articles, and that automating release deployments is the way to go.   At least with an automated tool there is a standardisation and simplification of process, and the possibility of improving it by adding more featues. 

A bit of background from my place (hopefully you wont cringe), we have a simple VBS script (yeah I know boring!), but it doesnt need any configuration to be used.   Just copy the scripts and DTS packages into pre-defined folders, run it (specifiying the database and SQL server), job done, with a nice little log file and a "release history" table in each database which records all releases applied to a database, when, by whom, success/failed (damned handy!).  Its not perfect, and requires the sql scripts to be full of conditional logic,  but overall it has made a massive reduction in the number of issues related to db code deployment, which we used to do using custom scripts for each release. 

ok... think Ive been writing too much, best go...

Take it easy, good luck.

Kev