Hi Bernard,
> 1. I actually want to know if there is any way to trap that error in VFP instead of what happens now - the internal VFP error message is displayed, bypassing my OnError and Form.Error code.
If the error event is not firing in your case, that is, the error message is not the result of an error inside an error handler, than you can't catch it. There are workarounds, but they aren't simple SET commands:
- If you can track the error to certain lines of code, you can use the _Execute VFP API function. You need to write a small FLL that calls the function.
- If the affected part is more than a line but still relatively isolated, you can move it into a COM server. For the COM server you could specify additional options like enabling unattended server mode. If the COM server runs into error, you could shut it down from the main application and create a new instance.
- The error occurs when the network is temporarily not available and SMB sessions are closed. VFP cannot recover from such a error. If VFP opens a file and file becomes later unavailable, VFP won't open the file again. Therefore, you can minimize the error by minimizing the time that you open tables on the server.
- You could keep a file open on the server yourself and use LLFF like FREAD() to access the file. If this fails (FERROR), you know that you shouldn't try to access one of the tables, because that will trigger the ISO error.
- You could also move the data access code to the server on which the files reside. This turns file access into local file access and is less vulnerable. Use sockets, DCOM or web services for the communication between client and server.
The best way, though, is to fix the network.
--
Christof