Part 2

There's nothing in the code sample that looks problematic to me.

In relation to attempting to determine the overall root cause of header record count "corruption" I would characterize this code as:
- NO buffering in effect;
- NO TRANSACTION in use;
- EXACT is ON;
- USEs all as SHARED and into numbered work areas;
- Tables always SELECTed prior to APPEND BLANK or REPLACE;
- SELECT is always by work area number;
- APPEND BLANK always follows a SCAN/ENDSCAN.

It will be interesting to see how other problematic applications compare.

>I dont know when the corruption occured. The app that ran that process was vfp7, until recently, today. However that process is the only thing that happens to punchparams.dbf except for normal form interface record editing. It is very unlikely that 2 users were trying to access the same record at the same time & that process executes after hours.