The big Q. is Why does anyone below sysadmin have Delete authority in the folder in which the DB resides?
----- Original Message ----- From: "Oma Cox" <[EMAIL PROTECTED]> To: "RBG7-L Mailing List" <[email protected]> Sent: Wednesday, February 02, 2005 12:42 PM Subject: [RBG7-L] - Re: Sys_Rowver > Marc, > > I've used a software package to monitor and catch users that like to > wonder and do things. > > The link is below! Not too expensive if you compare your time charges > to the client for recovering from those strange events affecting their > Rbase application. > > This package is completely invisible to virus and spyware! > > I also use it to help clients that want to spy on their children and > spouses! LOL > > http://www.spectorcne.com/ > > > Best regards, > > Oma Cox > > > -----Original Message----- > From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Marc > Sent: Wednesday, February 02, 2005 5:25 AM > To: RBG7-L Mailing List > Subject: [RBG7-L] - Re: Sys_Rowver > > > Bill > > R:Base is great and as usual the problem is between the > chair and key board. > > One office called and said "my program will not start" > Turns out they had somehow deleted 3 of the 4 RB > files. This same office called a month earlier and somehow created a > sub folder and moved the 4 RB files into that sub folder. > > Of course they don't know how this happened! > > Marc > > > > ----- Original Message ----- > From: "Bill Downall" <[EMAIL PROTECTED]> > To: "RBG7-L Mailing List" <[email protected]> > Sent: Tuesday, February 01, 2005 6:54 PM > Subject: [RBG7-L] - Re: Sys_Rowver > > > > Marc, > > > > Ah. It's not a fear of R:Base doing something you don't like, it's a > > fear of people doing something you don't like! Sys_rowver does not > > give you much of an reliable audit trail. Someone using a form could > > easily save a row an extra time. Any update of any column in the table > > > increments sys_rowver, too. > > > > I wrote one application a few years ago that did it's own audit trail: > > > everytime a row was deleted from a sales details table, a trigger > > logged the delete in a totally separate table. Through that mechanism, > > > the company figured out that one salesman had been repeatedly entering > > > bogus orders to "hold" stock, then deleting them, freeing up the stock > > > just before the time that employees were allowed to buy unsold > > merchandise at big discounts. > > > > Bill > > > > Marc wrote: > > > > >Hi Bill > > > > > >We same daily totals for charges, payments... in a Recap table. This > > >office called and said their monthly recap totals are off. I had them > > > >send me their data and it appears someone has been changing their > > >data. I am not sure if these changes are everyday housekeeping or if > > > >someone is walking off with a few checks in their pocket. > > > > > >Marc > > > > > > > > > > > > > > >----- Original Message ----- > > >From: "Bill Downall" <[EMAIL PROTECTED]> > > >To: "RBG7-L Mailing List" <[email protected]> > > >Sent: Tuesday, February 01, 2005 11:39 AM > > >Subject: [RBG7-L] - Re: Sys_Rowver > > > > > > > > > > > > > > >>Okay. You made me ask: why is that fearsome? > > >> > > >>Marc wrote: > > >> > > >> > > >> > > >>>Thanks Bill > > >>> > > >>>I was afraid of that. > > >>> > > >>>Marc > > >>> > > >>> > > >>> > > >>> > > >>> > > >>>>Marc, > > >>>> > > >>>>Exactly. When the row is inserted, the value is zero. Each time > > >>>>the > row > > >>>>is updated, the value is incremented by one. It's the "version > number" > > >>>>of the row. > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >> > > >> > > > > > > > > > > > > > > > > >
