One thing to add to that:
they must supply some sort of change request doc with MANAGEMENT/USER
sign-off on it before you run the changes.
just supplying a piece of paper doesn't do it for me. I've had
developers (yes, developers not duhvelopers) who still say "oh I tested
it" but I want something that proves someone other than the developer
looked at the results.
If this is going to be an ongoing process, create change control forms
for it.
Rachel
- Jared Still <jkstill_at_cybcon.com> wrote:
>
> Dennis,
>
> If management is Ok with this ( have you asked? ) you need to
> take some steps to protect your database, your job and your
> reputation.
>
> 'cuz the duhvelopers will do their best to destroy all three.
>
> 1. You need a test database with a reasonable amount of test data
>
> 2. Your duhvelopers need to develop their data massage routines
> against the test database.
>
> 3. When they think they have it right, run the query on the QA
> database.
> If resource/time constraints demand it, this might be your test
> database.
>
> 4. They need to check their results. This means that an actual user
> that is very familiar with the application will use the
> application
> against the QA database, and sign off on the results.
>
> 5. Don't give them an account on the production database. They must
> supply you the DBA with script that you will run. They must
> supply
> documentation with the script. If the docs are imcomplete, don't
> run
> the script until the docs are complete.
>
> Anyway, this is what makes me happy. :)
>
> Jared
>
>
> On Tuesday 28 May 2002 15:25, dmeng_at_focal.com wrote:
> > Hi folks -
> > I have received a stream of requests from developers/production
> support (
> > yep, same group, dont ask ) to do ad-hoc data massaging in the
> production
> > databases. Since I don't know the applications that well, it's hard
> for me
> > to push back these requests when told that if the script don't get
> run
> > today, marketing department won't be able to use the system etc. I
> wonder
> > if other people on the list have the same problem and I am thinking
> about
> > coming up with a document for the developers to fill out making
> sure the
> > request won't hose up the database. I wonder how other shops deal
> with
> > issues like these and can you let me know what you can do to check
> for
> > potential issues with a sql script.
> >
> > TIA
> >
> > Dennis Meng
> > Database Administrator
> > Focal Communications Corp.
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: Jared Still
> INET: jkstill_at_cybcon.com
>
> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing
> Lists
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Rachel Carmichael
INET: wisernet100_at_yahoo.com
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
Received on Wed May 29 2002 - 08:08:49 CDT
