Hi,
What you say would be nice, but it is difficult to do when the exe has lost its connection to the resources it needs to gracefully respond or exit, (especially if the exe resides on the network drive).

The simple example is this, if you cut your head off, you would have great trouble communicating to others what the problem is, and you would have great trouble fixing the problem yourself.
So asking VFP to overcome a similar problem is asking for too much.

As for Network installations that disregard the specifications and cause application errors as a result, the only reply I have is to fix the out of spec problems or show the network engineer the door.

>>Hi,
>><snip>I guess the Fox team still have some work to do
>>
>>What would you suggest the Fox Team to do, run training sessions about "It is not a good idea to unplug a network cable whilst accessing a networked Database application"
>>
>>Wake up, it is a catastrophic infrastructure failure.
>>
>>The only thing that can be done is 1. Run using terminal services or 2. Run a SQL Database backend and handle the disconnects and reconnects within your code.
>
>At the company where I work, we have UTP cables that cover at least 130 meters (or so they told me - I am not involved in the networking stuff). (Note: 100 meters is an absolute limit.) I can't blame the VFP, nor the framework, for the resulting problems - but I do wish the errors would be handled a little more gracefully. IOW, if the cable gets disconnected, or if there is network congestion, the user might get an option to plug the cable, or wait a while, and try again. Right now, errors are NOT handled very gracefully - plus, I get index corruption without any warning message. I guess a client-server setup would help there, but right now, a transition would require a large investment in programming time.