>>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.
>
>Now, I might be willing to easily believe that reading the DBF out of the EXE might be a problem, but I know I've done that kind of stuff before.

I meant the executable, as that's the critical part. The user may have had one form open for a whole hour, and then wants to run a report of what he did, and that's in a piece of the exe which wasn't loaded, including some pieces of the internal table with, say, list of reports. If the file handle to the exe was closed by windows at the time, I'd expect some problems.

Let's face it, Fox was written when a file handle stayed forever, when file and record locks were trusted and when they still haven't tried to optimize things. Now these optimizations all go against this trust in handles and locks, so any ISAM record system will break and force you to go client-server. But it also hurts the partially loaded exe from the app server. IIRC, that's called software rot, when your app doesn't change but the underlying OS does, and some things which always worked and we took them for granted don't work (that way) any more.