Click here to monitor SSC
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in
Home       Members    Calendar    Who's On

Add to briefcase

Version Control - Migrating Objects to Production Expand / Collapse
Posted Saturday, November 10, 2001 12:00 AM



Group: Administrators
Last Login: Friday, August 26, 2016 9:20 AM
Points: 34,087, Visits: 18,224
Comments posted to this topic are about the content posted at

Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1604
Posted Saturday, August 7, 2004 8:44 PM


Group: General Forum Members
Last Login: Thursday, October 4, 2007 10:09 AM
Points: 198, Visits: 2
Steve - the HTML title of this is wrong I think. it is same title as #3 so when you add them to favorites this one overwrites #3 - just a note

good series

Brian Lockwood
ApexSQL - SQL Developer Essentials

Stand up for an Independent SQL Community - be Informed
Post #130696
Posted Thursday, March 31, 2005 2:58 AM


Group: General Forum Members
Last Login: Wednesday, May 29, 2013 3:58 AM
Points: 167, Visits: 97

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.


Post #171097
Posted Thursday, March 31, 2005 8:07 AM



Group: General Forum Members
Last Login: Thursday, November 13, 2008 9:13 AM
Points: 499, Visits: 76
Having rollback scripts for text-based objects like stored procedures, triggers, views is one thing (relatively easy) However, having rollback scripts for scripts that change structure, rearrange data, etc is entirely another. In my career, we never do this ahead of time, but only if there is a problem in rolling out the original structure change, then we attempt to fix it from the state that the problem left it in and go from there.  -Vic
Post #171201
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse