>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.