Re: Direct DB Access for non IT users

Jeff,

Put all of the dml code the user will need into procedures and only give them execute privileges on those procedures. That way they will have no way to modify or read the data. You also won't have to worry about locks since you can include the commit in the procedure.

Seth

On Wed, Dec 22, 2021 at 1:25 PM Jeff Chirco <backseatdba_at_gmail.com> wrote:

> We've written a bunch of custom applications for various departments in
> our company but unfortunately because of time constraints screens were
> never developed to modify configuration type data, nor will time be given
> now. Things like lookup data, new codes or assignment data. The developers
> get those requests from the user and then write custom scripts to update
> the tables. A proposal is out to give SQL Developer access to dedicated
> individuals in the various departments to handle this type of work to
> alleviate the workload on the developers. As a DBA I am not fond of these
> people having direct database access to add and modify records. We are not
> talking about sensitive data or the main application data. I feel it is
> still a security issue, there is a chance they don't fully understand and
> do it wrong or leave table locks open.
>
> Do any of you have these issues and how do you handle them? Given end
> users direct access?
>
> Thanks,
> Jeff
>

--
http://www.freelists.org/webpage/oracle-l