>Hi Hugo,
>
>what I think is being pointed out is that if you run your app from the network, your error code won't be able to run, wherever you have that in your app. That's a big difference from a local install, where at least you (should) get the information that the network was disconnected.

We have several dataloggers, programs that run 24/7 collecting data and we were never able to trap errors related to a network connection loss, even though the executables are local when there is a network error it is not trappable (in our experience) and we would end up with either an error reading file or an invalid seek offset, we tried several things to keep this from happening to no avail, in the end our solution was to split the process in two, one that receives the data (normally it is data coming from serial ports) and saves it locally and another process that "slingshots" the data from the local storage to the network, so the first one will never die even in the event of a total network failure as it is not using any shared resource, the second one can die, but we would not lose data as the captured data will still be cached in the local storage and moved after the networked application is restarted after said network failure.

In short, if you have a networked table open and the network goes down, you cannot trap the error (or we failed miserably) (this is not the same as trying to opening the table while the network is down, that is easily trappable of course.