>I have posted on this a few times over the past year, and admittedly, this took way too long to solve this (several months of me and 3 NT techies spending considerable time & resources testing and analyzing). Especially considering the simplicity of the answer. But finally, we have isolated both the rough cause and the exact solution for my VFP6/NT Invalid Seek Offset (vfp 1103) errors, if this may ever help anyone. It was a real champagne day for us, I'll tell you, solving a problem as tough as this one has been.
>
>The error, in this case, has apparently little to do with indexes, opportunistic caching, or network interrupts, the usual suspects, although my guess is that the NT caching was fouled up somehow by the below factors.
>
>The always-fatal, and extremely frequent "Invalid Seek Offset" errors (#1103) in my largest vfp app were caused by a combination of two factors, both purely client NT:
>
>1) A slightly older NT Intellimouse driver version, the standard in our slightly old ghost-install NT configuration.
>
>2) Some WIN32 API Mouse Pointer calls (LoadCursor, etc.) in my vfp app.
>
>It took extra long to solve this because merely changing only one of these two factors did not entirely stop the errors, it just reduced them. Therefore anyone seeing this error should look at both these things, but especially #1, since that's a more common situation.
>
>The vfp debugger and NT logs stopped at random code and memory areas, completely unrelated to the API calls, not helping at all. Also, we kept dwelling on index, table, and caching problems due to similar 1103 problems of the past - a waste of time, as it turned out. Wrong place to look.
>
>Perhaps this is only a superficial diagnosis & solution of some deeper NT problem (like caching), but I'm ready to lay the blame squarely on the above culprits. Change them, and no more problem.

Well, that's a pretty good definition of finding the problem ;-)

I had a similar situation some time ago. A client ordered a bunch of new Dell W98 workstations all with Logitech mice. They found that DOS boxes running their DOS accounting program were always suspended if not the foreground application; a real pain when wanting to run long accounting batch jobs and do other work in the meantime.

Eventually traced the problem to the Logitech 8.03 mouse driver; replaced with the 9.0, problem solved.

I still find it difficult to believe that the mouse driver could have such a major and fundamental effect on the system, but I can't argue with success.