10.1B unknown cause for record deletions

[jpfuentes2]

I have a 10.1B progress hosted on a 64 RHEL box. We made the switch from 9.1E to 10.1B over a year ago and thus far haven't experienced any serious problems until lately.

We have a certain table where records are being removed from the table without a known cause. My problem is two-fold: 1) the same set of records are being deleted 2) it is occurring at different times of the day. We use a mix of ODBC/4gl scripts and I cannot find anything that would cause this. The first reason being that we do not have any cron jobs set up on our servers to run any kind of app that would even come near that table, much less delete records. Also, as I said, the records are being deleted at different times: sometimes during work hours and sometimes not (I have a cron job which copies the table so that I can audit).

The other issue is that our progress software is provided by another vendor which means I cannot directly contact progress for support. I had our vendor do an online index check which did nothing. Last Wednesday I had him do an offline index rebuild and I have not seen any records deleted yet. They would normally have been deleted by now.

The offending table has 26 fields and 3 indexes. The primary is a username field with 2 others. My problem is further compounded by the fact that it is the same records being deleted each time and in increments. What I mean by this is the same records for that username are being deleted everyday, but in incremental steps.

My mind tells me it is an irrational belief to hold that the database is surgically removing the same records. It makes more sense to believe that some kind of cron job is deleting records by a particular query for that username; however, access is limited to the machine and I have already inspected those points of entry.



Does anyone have any ideas? Could it possibly be that the offline index rebuild solved our problem? If so, does anyone have any potential explanations?

 

[TomBascom]

Use ProTop to monitor the table. (You have 10.1B so unless you have a 10.2 license sitting around you will need the character download.)

You will need to make sure that the -tablerangesize startup parameter is large enough to cover the table in question.

Select "Specific Table Users and IO" and then use the "e" command and enter the table number to examine the table in question. When someone deletes records you will see it happen and know who did it. You might want to set the interval (the "i" command) to something longer than the default 10 seconds if you do not have a good idea when it is going to happen.

If you were running 10.1C or better you could also trace what program was being executed and tell your vendor what line number of that program committed the offense.

 

[cj_brandt]

Have you considered enabling Progress Auditing on the table where the records are being deleted from ?

 

[timk519]

Does anyone have any ideas? Could it possibly be that the offline index rebuild solved our problem? If so, does anyone have any potential explanations?

If you can rule out sabatoge, my guess would be that something dynamic is doing the deed.

 

[TomBascom]

This is usually just a result of sloppy code somewhere.

I once had such a problem that was caused by a programmer forgetting to specifiy the middle field of a 3 field key in the WHERE clause. It deleted what it was supposed to delete, no problem. It also deleted lots of other stuff... to the users it seemed quite random

 

[jpfuentes2]

Thanks for the responses. I am going to speak to our vendor about table auditing. I'll also look into using your program, Tom.

I think I can safely rule out sabotage as very few people can access the screen to delete those records. I agree it could be sloppy programming somewhere. I suppose I have more research to do. I'll let everyone know what I find out.