>>The SQL Server is local so I will stop the service. But I wonder what actually happens on the customer SQL Server; as far as I know, nobody stops the server. And I doubt that they unplug the LAN card. Yet, I get these messages "Communication link failure."
>
>Another way to simulate it is to change the value of your handle - wrong handle, no connection (even though the connection actually still works, but you are using the wrong handle).
>
>Other possible reasons for disconnects are bad cables, bad plugs on cables, overcrowded network (so your failure is not really a failure, just a timeout), users unplugging the desktop to plug in a laptop (I've seen this happen, you wouldn't believe), some machinery creating electrical noise (x-ray does it, welding does it, strong enough speakers may do it, large electrical motors starting may do it)... and then there's more.
So far I can successfully "break" the connection by stopping the SQL Server (as Borislav suggested).
As far as what you list for possible reasons for disconnect, you maybe very much right. This is why I am adding this to my application - always to check before connecting (in LOAD of a form) is the initially established connection handle is still valid.
"The creative process is nothing but a series of crises." Isaac Bashevis Singer
"My experience is that as soon as people are old enough to know better, they don't know anything at all." Oscar Wilde
"If a nation values anything more than freedom, it will lose its freedom; and the irony of it is that if it is comfort or money that it values more, it will lose that too." W.Somerset Maugham
