Well it might take a little work, but this is what I would do. #1 - I would lock the table down with access control as tight as practically possible.
Add a single character field to the table to use as a Delete Flag (hangover from the old DBase days, using an asterisk (0x2A) as the marker or something else as your choosing). Having done that, you would have to change your code to exclude those marked as deleted. To the above, you might also add another table with just a datetime column that is added by a trigger from the main table that is updated ANY TIME the table is accessed (this will give you a timeframe to point to user activity involvement at the time of ANY access or deletions) Add a second table, as you have already done to contain just the records marked as deleted. This would be to determine if there are any actual deletions occurring in either table and if there are any deletions, is there any commonality to the deletions. It seems as the detective work is pointing to user access being the culprit, but maybe by taking extraordinary steps, it can be conclusive one way or another. On Saturday, March 12, 2022 at 2:45:33 PM UTC-5 Karen Tellef wrote: > Adrian: I am assuming they were actually deleted. Since the trigger is > "before delete" and operates as it should other than giving me that null > DeletedBy, and I can't find them anywhere in the original table, I have to > think they were deleted. If there was an issue with indexes or a database > problem itself, I would think it would show up on an Autochk. This > database has never had a bad Autochk. > > Karen > > > -----Original Message----- > From: Adrian Huessy <a.hu...@huessy.com> > To: rba...@googlegroups.com <rba...@googlegroups.com> > Sent: Sat, Mar 12, 2022 11:14 am > Subject: RE: [RBASE-L] - Delete Trigger mystery? > > Karen, > Quick question: do you feel that records are/were effectively deleted or > do you have NULL entries even though nothing was deleted? > BR, Adrian > > *Von:* 'Karen Tellef' via RBASE-L [mailto:rba...@googlegroups.com] > *Gesendet:* Samstag, 12. März 2022 01:02 > *An:* rba...@googlegroups.com > *Betreff:* [RBASE-L] - Delete Trigger mystery? > > > Why I needed the before-delete trigger: *no one* should ever be deleting > data from this table. And although they have the full version of RBase, no > one knows how to "get to the R> prompt". There is a monthend routine that > the senior user runs that will delete a batch of data, but that's all (we > remove the trigger before this monthend routine, then put it back on) > > Yet every now and then we find data mysteriously disappeared. > > So I created a before-delete trigger. It takes the record to be deleted > and appends it to an archive table. 3 columns in the archive table will > hold the deleted date / time and the user who deleted it. Works perfectly > at my development environment and when I test it at the place where the > database is installed. Records the date, time and the user. > > However, twice now we have found records in that archive table that had > been deleted (hundreds at a time). The records had the deleted date/time > but had *NO *user name. > > Here's the code I use in my stored procedure. The DeletedDate and > DeletedTime works fine, it gets updated every time. There is no login to > this app, so I grab the NetUser (used many times in the application for > other things, successfully). The first time that the archive had no user > name, I modified the stored procedure to grab the ComputerName. But still, > nothing..... > > > SET VAR vText TEXT = NULL > SET VAR vText = (CVAL("NetUser")) > IF vText IS NULL THEN > SET VAR vText = (CVAL("ComputerName")) > ENDIF > > UPDATE ClaimsDeleted SET DeletedDate = .#DATE, DeletedTime = .#TIME, + > DeletedBy = .vText WHERE claim = .spClaim > > > > Can anyone think of anything else I can trap that would help me figure out > how/when the records got deleted? > > Or does anyone know how records could get deleted when there *actually is > no* NetUser or ComputerName? > > > Karen > > > -- > For group guidelines, visit > http://www.rbase.com/support/usersgroup_guidelines.php > --- > You received this message because you are subscribed to the Google Groups > "RBASE-L" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to rbase-l+u...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/rbase-l/1654695576.980450.1647043308102%40mail.yahoo.com > > <https://groups.google.com/d/msgid/rbase-l/1654695576.980450.1647043308102%40mail.yahoo.com?utm_medium=email&utm_source=footer> > . > -- > For group guidelines, visit > http://www.rbase.com/support/usersgroup_guidelines.php > --- > You received this message because you are subscribed to the Google Groups > "RBASE-L" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to rbase-l+u...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/rbase-l/dbba74c3572c4f6aa054b424fd42d70b%40huessy.com > > <https://groups.google.com/d/msgid/rbase-l/dbba74c3572c4f6aa054b424fd42d70b%40huessy.com?utm_medium=email&utm_source=footer> > . > -- For group guidelines, visit http://www.rbase.com/support/usersgroup_guidelines.php --- You received this message because you are subscribed to the Google Groups "RBASE-L" group. To unsubscribe from this group and stop receiving emails from it, send an email to rbase-l+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/rbase-l/ff8ce79d-ce09-43b8-a3fc-48a36de02ca2n%40googlegroups.com.
