>>In this case, the user is opening up two indexed (not filtered) tables, scanning through anywhere between 5,000 and 75,000 records (depending in the credit union ATM and POS volumes) and electronically matching records based on various criteria. The user received the error while scanning through the tables and doing the matching - and there were no other users on the system at the time. This is reconciliation software that does intensive number crunching and before the record matching takes place I make sure the user can open the two tables exclusively. (for the short time it takes to do the matching this isn't a big deal) <<

Yes, yours is a curious situation. I have not experienced "Invalid seek offset" errors in the situation you describe. For "batch" processes, I also place strategic File, Record and/or semaphor locks ... and have never run into a problem. (Then again, the failure rate of any process, for whatever reason, is directly proportional to the time it takes to complete).

It was only in Multi-User (data entry/maintenance) situations where it is not practical to hold a lock for any period of time and the "current record" went "out of scope" (got "deleted", logically or physically by another user) that I encountered a problem (when not compensating accordingly).

(I also think one "may" need to watch out for ORDERs that are toggled between ASCENDING and DESCENDING, on the fly, for tables opened in multiple WA's with the same ORDER set ... due to the ASCENDING / DESCENDING "switching bug". Another "context change" that VFP may have a problem dealing with).