Re: Drop by accident?

"Michael B. Allen" wrote:

> In article <3CF4FB6E.1B145BFE_at_exesolutions.com>, "Daniel Morgan"
> <dmorgan_at_exesolutions.com> wrote:
>
> > "Michael B. Allen" wrote:
> >
> >> How common is it to drop records by accedent? We had ~2000 company
> >> records zapped today and no one is fessing up. Is it common that
> >> someone could drop records like that and then type commit without
> >> realising it?
> >>
> >> --
> >> http://www.eskimo.com/~miallen/c/jus.c
> >
> > Very.
> >
> > And the cause is generally one of the following:
> >
> > 1. Inadequately thought out and enforced access permissions
> > 2. Developers/DBAs mucking about where they don't belong
>
> Apparetly someone was using Microsoft Acccess to view records. Another
> user VNC'd into that workstation and not knowing what they were looking at
> deleted them by accident.
>
> Mike
>
> > 3. Delete statements with poorly constructed WHERE clauses
> >
> > For now I would use log miner to find out who, what, why, and when.
> >
> > Then solve the immediate problem and consider creating an audit trail
> > enforced by after delete triggers on tables with critical data.
> >
> > Daniel Morgan
>
> --
> http://www.eskimo.com/~miallen/c/jus.c

Eskimo.com ... here in Seattle?

Allowing anyone to access an Oracle database with MS Access is about as likely to cause problems as playing Russian Roulette with a loaded revolver. The account they use should have a custom role like the following:

CREATE ROLE read_only
GRANT SELECT ON some_table TO read_only; GRANT SELECT ON another_table TO read_only;

Do not give these people CONNECT much less insert, update, or delete privileges. If you do ... you are playing ... well see the reference above.

If management forces you to let them have access put an UPDATE OR DELETE trigger on the tables and copy off the changed records to an archive table that is kept reasonably current so it doesn't grow too large.

Daniel Morgan Received on Thu May 30 2002 - 10:59:21 CDT