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 <[EMAIL PROTECTED]> 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, [EMAIL PROTECTED] 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: [EMAIL PROTECTED] > > 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: [EMAIL PROTECTED] (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: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
