Gerry,

Thanks for the additional info - seems like there can be a number of causes for this error (likely the reason why 'help' is no help with this one).

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)

The user in question had just upgraded to a new version of the software that required a new install (major changes to app table structures) - and run an upgrade program I wrote to move their historical records to an archive table (over 1,500,000 records). I think they may have not allowed the upgrade program to successfully complete. (i.e. they killed it before it was finished)

Anyway, they re-installed the software today, ran the upgrade as they left the office - so we'll be crossing our fingers and hoping all goes well tomorrow. This one really had us shaking our heads because about 25 other locations have upgraded to Version 2 over the last few weeks and there have been no other reported errors.

Once again, thanks for your input.

>>Thanks for posting this - I am currently trying to assist one of our users who is encountering the very same error. Hopefully this will be the reason for their problems. I'll post back when we get the problem solved.
>
>FWIW, I think a lot of "Invalid Seek Offset" errors are related to "filtered" tables in a Multi-User environment.
>
>For example, you make have a table filtered on ACTIVE = .T. (or something). And lets say one session is sitting on a given record. Now, another user comes along and changes that particular record's "ACTIVE field" to .F., or deletes the record, or changes the primary key (in a relation), etc.
>
>When you now go to "look" at that record again, the FILTER's "working set" (for lack of a better term) has changed, VFP get confused, and barfs out an "Invalid Seek Offset". The solution: create a (non-filtered) CURSOR. In every case, where I replaced a problem filtered table with a non-filtered CURSOR, the problem disappeared.
>
>I believe "Invalid Seek Offset" may also occur when "moving" to a record that has just been deleted by another User and SET DELETED is ON. This typically occurs when the program "repositions" after a given operation but has not made allowances for a "multi-user delete".
>
>In general, I think you can categorize all these types of errors as being related to a change to a current record that has made it "invalid" within the current "scope" (when just a short time ago, it was "valid" or within scope) ... hence, the "Invalid Seek offset" (even though we are not really "seeking", per se).
>
>Though "single" tables may be hard to control (re: multi-user changes/deleted), "hierarchical record locks" can minimize the problems when dealing with related tables.
>
>Just my opinion, though.