I have a method whose function is to read a text file, parse the file into component pieces, using a temporary text file, and then APPEND the resulting temporary file into a .dbf. Let me emphasize that the method currently runs flawlessly, but we have found an anomaly that may be of interest.

After the temporary text file is filled, an FCLOSE() is issued to close the file, and then after the APPEND, the temporary file is erased with the ERASE command. What we have found is that if this process is run on a medium-sized machine (PII-400), the process runs as expected, but when run on our production machine (PIII-700), the process will sometimes stop at the ERASE command with an error #1705 - "File access is denied". If the method is continued beyond that point, the rest of the method executes without further error, though on investigation, the temporary file will still exist.

Since there were no problems concerning permissions (plausible, since this is under NT4), we tried the possibility that the file was not really closed. FCLOSE(), however, was returning .T., and the file can be erased while the program is running through Windows Explorer. Just on a lark, I decided to try the theory that FCLOSE() is making an API call, and while VFP is happy that the call was successful and is willing to move on, the API call might still be working. In other words, the API call is asynchronous. And while on a "normal" (heh heh heh) machine, that might not make a lot of difference, on an exceptionally fast machine, VFP would attempt to execute the ERASE before the API call was finished. So I inserted the following statement just before the ERASE statement:

WAIT "" TIMEOUT 5

In short, it worked. I had already opened a support incident with Microsoft, and they agreed that this was a novel solution, even if they couldn't verify that FCLOSE() runs asynchronously. He noted that this method of introducing an arbitrary delay in the code, as well as INKEY() may have implications if one is writing a .dll, but for our purposes, it seemed to fix the problem. Too bad VFP doesn't have Tcl/Tk's "after" statement...

I think VFP may be getting too fast for itself again.