We are not a US based company but approach is similar. Real development environment is out of our scope - we don't maintain it. We maintain test cycle databases (normally 3 DBs for acceptance by different groups), several pre-production DBs (normally 3-4 DBs again for other groups), one production and one production look-alike (kind of post-production). Depending on functional requirements they are refreshed from prodution backup, functional refresh, or production based TTS. Changes are coming with new software versions and going through our record tracking system. -- Best regards, Alex Gorbachev On Sun, 12 Dec 2004 11:18:32 -0600, DENNIS WILLIAMS <DWILLIAMS@xxxxxxxxxxxxx> wrote: > Agree totally with the use of scripts to make database changes. > One idea is to base your development on a 3-database model. Production, > staging, and test (or development). Update the test and staging as required > by cloning production. This way you are guaranteed to have an exact copy of > production. > Ideally you clone by recovering a backup. That way you frequently test > your backups. > Staging acts as a buffer between test and production. Often you can't > refresh the test database because of various developer activities in > progress, so staging is where you test the changes before they hit > production. > This method is from ITIL. The only way to combat a massive force like SOX > is to pit it against another massive institution. > > Dennis Williams > DBA > Lifetouch, Inc. -- //www.freelists.org/webpage/oracle-l