Valerie - Here is what I've been doing. Say the application uses SCHEMA_A. Create schema SCHEMA_B and create all objects in that schema. Grant select, insert, delete, update access for all objects to SCHEMA_A. In SCHEMA_A, create synonyms to point to the objects in SCHEMA_B. Only give the developers the password to SCHEMA_A. Not as elegant as Joe's method that Kirti posted, but this has worked out pretty well just to deter schema changes.
Dennis Williams DBA, 40%OCP Lifetouch, Inc. [EMAIL PROTECTED] -----Original Message----- Sent: Friday, January 10, 2003 1:50 PM To: Multiple recipients of list ORACLE-L In a n-tier system that connects to the database with JDBC, how does a DBA keep developers from modifying the application schema without the DBA's consent or knowledge in a centralized development environment? The developers can have their own personal database on their desktops to program/test with but we have a problem with them making changes to the main development database as the application schema owner. They know/have the application schema username/password since it is used to make the JDBC connections to the database from the app server. Does anyone have links to defined change control processes that might help? Thanks in advance! Val Valerie H. Webber Management Systems Designers, Inc Database Administrator [EMAIL PROTECTED] 704-566-5321 -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: DENNIS WILLIAMS INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- 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).
