If you're concerned about the group possibly shooting themselves in the foot by dropping or altering the tables, you could use system triggers (create trigger restrict_drop before drop on schema ...). For the DML privileges, you could also trigger on those events and possibly check some of the connectivity and/or tool information. For example, if they logged in via SQL*Plus or some other direct tool (instead of the application), you could raise an error if they tried to delete or update data. While this isn't foolproof since wise users know about DBMS_APPLICATION_INFO, it is probably enough to keep things safe from non-technical business staff. Obviously, there are some side effects of triggers that must be considered, but you're looking for suggestions...not necessarily good suggestions :). May the force be with you. Dan ----- Original Message ---- From: "Sweetser, Joe" <JSweetser@xxxxxxxx> To: oracle-l@xxxxxxxxxxxxx Sent: Thursday, January 31, 2008 10:37:45 AM Subject: Looking for opinions... Situation is a "generic" database account that too many people know the password to. But they need to know the password for valid business reasons. Does it make more sense to limit that account's access to its' own tables or create a new account(s) and grant those the specific access they need? I like the second option for various reasons (auditability (is that a word?) and accountability to name two) but others think just controlling the generic account's access to objects is fine. To be a little more clear (and one reason why I don't like the first option), there would be different privs on different tables - select only on table A; select, insert on table B; select, update on Table C; etc). Even with using roles, something just sort of bugs me about an owner/account not being to update its' own data (read-only situation exceptions, of course). Opinions/comments/suggestions? Feel free to send back-channel and I will summarize since I don't think this falls under a technical umbrella. :-) Thanks, -joe