>These are vfp6, only under NT, errors, related to tables I've posted about previously. I've done a thorough check on Opportunistic Buffering and similar registry settings, and that is not the problem, I am very sure. Setting Oplock off cut vfp performance incredibly, by more than 50%, at least. It did not help the Invalid Seek Offset ( and several other related) errors, but that's a good thing, I would hate to operate without it. I disabled all timers, too, just to be sure that wasn't related.
>
>I have narrowed down the problem on NT machines even further, and it grows more bizarre. I put the entire application and all data on the C: drive of an NT machine, and still get the errors, sometimes after a only a minute or so, and sometimes not for as much as 5 minutes of activity, doing table I/O, etc. I have tested on 2 NT machines, completely different hardware.
>
>Here is what occurs: the aliases remain in the vfp Datasession window (and the DBCs in the vfp dropdown), but the application cannot find them. Even stranger, it loses an entire DBC at once. No table in a DBC can be opened or found once an ISO error hits - every attempt to open a table or view in the DBC results in an ISO error or other error, but ISOs always are the first error. The tables sometimes can be opened to BROW from the Datasession window, but they are empty, and vfp usually closes right up angrily if I do this. It affects only one DBC at a time, others open are still functional. It occurs with different DBCs, and I have recopied & rebuilt and Validated them to be sure nothing is wrong with them. NT/vfp just loses them. It is not on attempts to open new tables all the time, so it is not a question of number of file handles, something like that. How can a DBC be lost? How does vfp internally use DBCs to access tables contained in it? Can this be an NT memory problem?
>
>Looking for new ideas...

I keep thinking back to one of your earlier posts, where you said that by logging into an NT box under a certain account, you did NOT get the ISO errors. That really sounds like a permissions issue.

It might be worth while to hire an outside NT guru, someone specifically NOT part of your organization and who has no preconceived notion of how NT security "should" be set up. Get an opinion on your current structure. You could also get a test machine set up with a different structure if that may be more "industry-standard".

Do you have any high-security features in place (just a WAG - maybe something like Kerberos)?