1) If you setup the roles as suggested, the developers can't do much damage with other tools, except, perhaps, to create a killer query. But you can control this with profiles.
2) Create roles that have only SELECT privileges. These roles can be default roles. This will allow reporting via 3rd party tools. The roles which allow updating can be enabled through your application as suggested in earlier posts. 4) The links should connect to your database as users that have limited access (only SELECT rights if possible). If I recall correctly, you can create links that use the username/password of the person accessing the link. This would require you to maintain the user's login in both databases. Jay Hostetter Oracle DBA D. & E. Communications Ephrata, PA USA >>> [EMAIL PROTECTED] 01/04/02 11:50AM >>> Thanks all ... The problem doesn't end here ... the requirements (loosely specified) are as follows 1. Developers and end users can access production ONLY through FORMS APPLICATION. 2. End users can't get to sqlplus so I am not even worried about that. It is developers that I am worried about. 3. Enabling roles at runtime is an option as long as we are not talking about reports. We use SQR and Oracle reports, a reports agent looks up requests and creates shell files on Unix server which are then scheduled to run. This scheme should work there as well. 4. How about people accessing tables through db links? I don't think there is a 100% proof method, but basically I want to be able to restrict developers accessing the instance except through forms application. Dropping developer's accounts is not an option. I thought over it, discussed it with my senior DBAs and finally I am turning to you guys. All the suggestions are helpful but I'd like to avoid as many loose ends as possible. Thanks in advance Raj ______________________________________________________ Rajendra Jamadagni MIS, ESPN Inc. Rajendra dot Jamadagni at ESPN dot com Any opinion expressed here is personal and doesn't reflect that of ESPN Inc. QOTD: Any clod can have facts, but having an opinion is an art! -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jay Hostetter 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).
