>>>>>however, I also think that the the error has to do with the loading of the targeted chunk of the exe.
>>>
>>>I think you're right. Our experience was that the culprit stand alone dbf wasn't corrupt, it just wasn't in correct state during a tick when VFP needed it. Who knows whether multiple cores allow some clever OS process to be in the throes of declaring completion in the exact tick when the VFP thread accesses it. An intermittently affected table in an exe that clearly can't be corrupted without editing the exe while it runs, could be the same phenomenon or a red herring.
>>
>>Since 1998 I observed the behavior of Windows networking where it closes files on you because it's either QoS or some other optimization, and having a file handle open for as long as several minutes makes your handle a candidate for recycling. Then a tech comes from support, opens a doc file over the network, changes it and saves and says everything's fine with the network.
>>
>>Now a VFP exe stays open for the whole duration, and who knows how many times the handle gets released and then recreated. Somewhere in that process there may be a glitch (related to SMB2, perhaps, who knows) so that the block containing the pieces of table read so far and the pieces read after the reconnect may not be quite in sync - and bang, ISO.
>>
>>Which is why I don't trust M$ networks to keep anything open longer than a few seconds. Copy it to your %temp% and use it there. Sort of beats the purpose of networking but so it is. File level client-server. Help yourself with the files you need and hold them close to your chest.
>
>Dragan, I disagree with the need to copy the file/dbf over to the TEMP folder. When FoxPro does a select into a cursor and the result set is rather small or even if it's big it puts as much into memory as possible for performance reasons. And it also creates a TMP (I think that's the extension) in the TEMP folder. Now, it may never push data to the TMP file, but FoxPro is file based even though it buffers as much as it can in memory. So, it needs the TMP file. Dmitry should select * into a cursor if there's a problem.

Jeff, this is not about dbfs or queries, but about the EXE itself. It is unlike other EXE files, reading from itself when running it. When the network connection is broken, it wll raise an ISO when running from the network. You'll not have that problem when running the exe locally.

You will still have a problem when connected to networked DBFs though. That is why we moved away from networked dbfs and went SQL server a long time ago.