Second, first: If the system on the crappy network runs on Pervasive PSQL, enabling AutoReconnect on both the server (restart services required) and the client, can help to mask network problems. Except for a momentary delay during a reconnect, network hiccups are largely transparent to the client application.

First, second: I'd suspect some network resource is going to sleep. Microsoft keeps getting more and more aggressive with power management. I used to think, 'mapped drive letter'. But nowadays, it can be any USB device, they're so ubiquitous, mapped drive letter or UNC, no matter. In general, however, I also find people are becoming less and less patient with computers. If it's not instantaneous, users very quickly become ruthless. But I digress...

Failed to open, table... always seemed to me to be related to the Magic lock file, mglock.dat, by default, and if the resource has gone to sleep, it can't open the lock file. Sound like a good guess? [To where] Is the lock file being redirected?

I usually use On error:Recover, because, for critical things, I've usually written an Any Error handler of my own. Unless it's an unattended batch task, then I often want the task to abort and just write the event to an error log.

Steve Blank