Re: database version control question

From: Tom Zamani <tomz_at_redflex.com.au>
Date: 2000/04/04
Message-ID: <8cbpk7$fqg$1@perki.connect.com.au>#1/1

Look, there is no clean way of controlling this issue, or I have not managed to find it.
However this is my sugestion which has been working for me.  1- instaul source safe (nothing to do with version control but it helps the developers)
 2- Intoduce the patch into your system

    create two patch directory for each application

        1 -Emergency
        2 -Not Emergency

group all the requested modifications in one week to a patch file or patch directory and give the file or directory a good name like p ||date or something like that.
 when you apply the patch to the development database change the name to applied DEV and date
then move it to production and apply the patch to production and change the name to applied Prod and date

so by looking at the patches at any point of time you would be able to tell what is in production and what is not.

If you found a beter method let me know
Tom

Nhuan_at_Lieu_NoSpam.org <Nhuan_at_Lieu.org> wrote in message news:8cbev6$c94$1_at_nnrp1.deja.com...
>
>
> Hi, I am relatively new DBA, in your opinion what is your suggestion in
> handling version controlling database changes from
> Development->QA->Production in an environment where the several
> developing teams have multiple and/or independent database change
> requests to the _same_ database at _different_ timeframe. Below is a
> typical example:
> DEV_TEAM1 have Table1 (increase a column size) & StoreProcedure1 update
> request and change priority is Important (not Emergency). This request
> to move into Production in 2 weeks. However, before the above change
> took place, DEV_TEAM2 request an "unrelated" functional change Emergency
> request to update Table1 (add an NULLable column) & StoreProcedure2.
> This second is to move into Production in 1 week. To summarize, Request
> 2 comes to DBA after Request 1 but need to move into Production sooner
> than Request 1 with one common & unrelated table change. To make it even
> worst, we have 7 such outstanding and similiar requests right now on the
> queue and I need to way to keep track of these changes as to minimuize
> impact.
> Any systematic way to help to manage this chaos is highly appreciated
> and would like hear from you on your person experience how you did your
> change management.
> Thanks.
> PS - I works in a startup where change requests occur weekly.
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
Received on Tue Apr 04 2000 - 00:00:00 CDT