April, Mike is right, but this also allows users to use the 'Examine' feature without knowing the APPS password - they can then make *data* changes *directly* to the database - a very strict Oracle Support no-no and a bigger problem. The issue with using a Non-APPS user is that APPS uses a ton of stored procs/pkgs which work only when used as APPS - this includes packages that set and use the ORG Id. I developed an alternative of allowing a set of users and developers to get to traces without the APPS password by setting the Utilities:Diagnostics to Yes at Responsibility or User level rather than at the Database level. This way, you can both *limit* the number of people that can damage the system while still not giving out the APPS password.
For the Senior Developers/Team leads/Support folks that *do* need the APPS password for sure, you can still build in a Database level DDL trigger that detects and records *any* DDL changes made. Use this to rap any knuckles connected to fingers that stray! Hth, John Kanagaraj DB Soft Inc Phone: 408-970-7002 (W) Grace - Getting something we do NOT deserve Mercy - NOT getting something we DO deserve Click on 'http://www.needhim.org' for Grace and Mercy that is freely available! ** The opinions and facts contained in this message are entirely mine and do not reflect those of my employer or customers ** >-----Original Message----- >From: Hately, Mike (LogicaCMG) [mailto:[EMAIL PROTECTED] >Sent: Wednesday, October 15, 2003 8:14 AM >To: Multiple recipients of list ORACLE-L >Subject: RE: Financials and APPS password > > >I could be missing something here. If you set the profile option >"Utilities:Diagnostics" to "YES" users are allowed to enable trace on a >session without having to provied the APPS password. > >Cheers, >Mike Hately > >-----Original Message----- >Sent: 15 October 2003 14:29 >To: Multiple recipients of list ORACLE-L > > >April, > > We lost this battle with our developers - they have the >password, along >with strict instructions to "behave." > Nobody else should have the password to any of the schemas >(APPS, GL, INV, >etc.). We create logins for users that need them and grant >the necessary >rights to objects. As you know, APPS can do just about anything in the >database, so you're asking for trouble if you let the whole company in >there. Chances are you already have some objects in that schema like >MICROSOFTDTPROPERTIES. > >Jay > >>>> [EMAIL PROTECTED] 10/15/03 08:39AM >>> > >Okay, anyone using Financials... E-Business suite... Oracle >11i... whatever >you want to call it... > >I am trying to apply SOME kind of security to my databases. >It appears that >it is critical for everyone to be able to access production >using the APPS >id.... Finance and accounting people, developers, everyone. What does >everyone else do in their setups? The newest reason is the >need to run the >new Mass Additions Trace which apparently requires that you >use the apps id. >We have found a way to set up any user with a read only >version of what APPS >has (since they have to be able to compile reports in >production and access >production data live rather than a month old clone), but >Oracle says that >you need to run Mass Additions Trace as apps. > >Does anyone let the entire company have the production apps >user's password? > > >April Wells >Oracle DBA/Oracle Apps DBA >Corporate Systems >Amarillo Texas > /\ > / \ >/ \ >\ / > \/ > >\< > \ > >\< > \ >Few people really enjoy the simple pleasure of flying a kite >Adam Wells age 11 > > > > >*************************************************************** >***************************** >E mail Disclaimer > >You agree that you have read and understood this disclaimer >and you agree to be bound by its terms. > >The information contained in this e-mail and any files >transmitted with it (if any) are confidential and intended for >the addressee only. If you have received this e-mail in >error please notify the originator. > >This e-mail and any attachments have been scanned for certain >viruses prior to sending but CE Electric UK Funding Company >nor any of its associated companies from whom this e-mail >originates shall be liable for any losses as a result of any >viruses being passed on. > >No warranty of any kind is given in respect of any information >contained in this e-mail and you should be aware that that >it might be incomplete, out of date or incorrect. It is >therefore essential that you verify all such information with >us before placing any reliance upon it. > >CE Electric UK Funding Company >Lloyds Court >78 Grey Street >Newcastle upon Tyne >NE1 6AF >Registered in England and Wales: Number 3476201 > >*************************************************************** >***************************** > >-- >Please see the official ORACLE-L FAQ: http://www.orafaq.net >-- >Author: Hately, Mike (LogicaCMG) > 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). > -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: John Kanagaraj 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).
