Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12»»

Database Change Management Best Practices : Achieving an Automated App Expand / Collapse
Author
Message
Posted Monday, July 12, 2004 3:43 PM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Monday, March 13, 2006 2:12 PM
Points: 31, Visits: 1
Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/DFuller/databasechangemanagementbestpracticesachievinganau.asp
Post #125956
Posted Monday, July 12, 2004 9:14 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 4:18 AM
Points: 5,245, Visits: 12,161
Lots of good points highlighted and looking forward to reading part 2.


Help us to help you. For better, quicker and more-focused answers to your questions, consider following the advice in this link.

When you ask a question (and please do ask a question: "My T-SQL does not work" just doesn't cut it), please provide enough information for us to understand its context.
Post #125970
Posted Monday, July 12, 2004 9:57 PM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Sunday, November 16, 2014 2:20 AM
Points: 146, Visits: 245

I am a proponent of the manual scripts method (with some automation ).

Most of the drawbacks listed by the author can be summarised as "its a big hassle for the DBA". This is true in many situations, especially for some table and index changes and I am interested in seeing part 2.

For the bulk of development which is stored procs, views, functions and new tables, I use a hierarchical directory of folders sorted in the order that scripts must be applied and have a script called RunSQL which runs all the scripts.

With reference data, my RunSql script can read text files in comma delimited form and these are kept in VSS.

Post #125974
Posted Wednesday, July 28, 2004 5:09 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Wednesday, January 26, 2011 7:44 AM
Points: 339, Visits: 11
I am fairly new to SQL Server and originally struggled with the manual approach but now adopt the following approach which seems to work very well for me.

I have a Business Testing environment where I simply restore the Production environment.

I then document the following so that it can be easily replicated during the Production Close.

I then use Redgate SQL Compare to update this enviroment with the changes in the Development environment. I of course scrutinise the changes carefully.

I use Redgate SQL Data Compare to update reference data tables where fields have been added.

And DTS Backup 2000 to copy all the DTS Packages.

Following Business Testing I adopt the same approach to update Production.

I save the reports and scripts created by Redgate. And back up the original DTS packages before deleting and overwriting them.



Post #128752
Posted Wednesday, July 28, 2004 5:16 AM


SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Wednesday, December 17, 2008 8:34 AM
Points: 108, Visits: 6

therefore you cannot say who updated what code and when with a complete history of all changes...

making the change is not change management.

Post #128754
Posted Wednesday, July 28, 2004 7:28 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Friday, February 25, 2011 8:56 AM
Points: 20, Visits: 11

Good layout of the common solutions.  We currently use the manual approach wioth templates for stored procs and triggers. This was working until we grew to about 12 developers.  Now it has become a mess since everyone is at different levels of sql scripting and some better then others.  We are currently looking for a new solution and are evaluating DB Ghost as a possible solution.  Any one use or heard anything about it?

Can't wait for part 2!

 

Jim




Post #128784
Posted Wednesday, July 28, 2004 9:19 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Monday, June 19, 2006 11:42 AM
Points: 13, Visits: 1

This looks like it's going to be a very good series of articles.  I'm always looking for ways to improve how we manage database change.  We are a small team, with myself (DBA and actually lead developer too), and 2 other developers.  We maintain 3 separate environments (Development, Beta and Production). 

Currently I am the only person responsible for any database changes - schema, stored procedures  and permissions.  I've implemented a fairly manual approach, but I use Visual Studio.NET with a database project to manage "groups" of changes.  VS.NET also will do some automatic scripting of schema changes, but you are on your own as far as stored procedure change scripts are concerned.  The drawback is that all "rollout" status of each DB project, as well as any interdependency between projects (project B requires project A be rolled out first) is all completely manual, and I track it all in an Excel spreadsheet for now.

This system is effective for our needs now, but as the team grows, I'm sure we will need to make some changes.




Dave Goerlich

Ross Environmental Services
Post #128821
Posted Wednesday, July 28, 2004 10:58 AM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Today @ 10:02 AM
Points: 851, Visits: 1,345
Good teaser article to have us looking forward to the next part. This really just highlights some basic methods that are currently used. Some suggestions on better alternatives will be greatly appreciated when part 2 comes along. We use a separate change-tracking/approval system right now. I look forward to seeing how it can all be integrated a little better.

-Pete Schott



Post #128855
Posted Wednesday, July 28, 2004 12:22 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Friday, October 27, 2006 9:17 AM
Points: 2, Visits: 1
Go to www.innovartis.co.uk and get the whitepaper.
Post #128879
Posted Wednesday, July 28, 2004 1:53 PM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Today @ 10:02 AM
Points: 851, Visits: 1,345
That's pretty disappointing. While I like looking at new products, it's a shame that this is pretty much leading up to "Use DB Ghost". How about those of us who just don't have a good software budget? It's difficult to justify purchasing another tool (even with the ROI calculator - that is a nice touch) to management. Anyone have some best practices that don't involve purchasing a new tool?

-Pete Schott



Post #128899
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse