>The other possibility that I have seen for this is that the app is on the server and connectivity is being lost for a short period of time. VFP will give that error when it can't read the app (which as you know is really just another table). Also even if the indexes are fine, if connection to the drive containing the database/table is interupted momentarily it will give that error. It means that the byte offset it is trying ti find is being returned as being invalid for the file in question.

I can add a little (make that a lot) to this, and this is sort of a status report on a problem I've posted here about several times in the past year:

What you describe is close to what I've found, with the "Seek Offset" error occurring in my testing of a large vfp6SP3 app frequently under NT4.6a, though never under Win9x running off NTServer. In addition, I have isolated the Seek Offset errors to being totally local in nature (at least in my case). It has nothing to do with server/network connections. In this testing, NT is not being run as a local server, either, just pure local WS, as simplified as possible.

IOW, I can reproduce the error, with a local NT account, no network connection line at all, with all data and app files local. After several of these errors, NT actually begins to "shred" files. First the indexes are corrupted, then the DBC, and finally the tables, so that entire DBs are trashed, and I have to copy/rebuild from scratch to re-test. I can trap the errors, and they are all related in some way to table/cursor/view code, but they hit at an extraordinary variety of code lines, and are always fatal.

Mysterious, but it's somewhat related to what you have described. NT quite clearly is "losing vfp cache offset byte addresses" (in approximate terms), from observing NT & vfp files. "Why" is the 64K question. I have found some related MSDN articles about assorted problems of NT having trouble handling shared data in general, with various data types: Fox, Access, Dbase, and others. Most of these have been reported fixed with some NT patch, or there are various suggested fixes such as dabbling with registry cache settings, etc., but nothing I've tried works.

In recent testing, I have tried a new approach: another new NT machine formatted with a FAT drive, rather than NTFS. I have not been able to reproduce the error thus far under FAT, FWIW. I need to test a little longer to verify this - sometimes this darn error does not manifest quickly, even with serious stressing, which is mainly what makes it so difficult to resolve. But the FAT vs NTFS thing will be interesting if true, a further isolation of problem.

This is, simply put, the stickiest technical problem I've had in my entire computer-life, I've been trying to debug it for a year now. In the meantime, no one can use my apps from an NT machine (and NT is Laptop standard here) - thankfully, other developers' non-vfp apps are having different types of problems running under NT, so at least I'm not alone with NT troubles. But if you have any other ideas, please jump in.