TMSConnection OnConnectionLost is not firing on Windows 7

rbrodner · Post by **rbrodner** » Thu 27 Oct 2011 22:03

I've been working with restoring lost connections, and everything is working well on XP:

If I disable the network adapter, the ConnectionLost event fires immediately when I try to do any database related activity, and I use rmReconnectExecute to re-establish the connection.
If I physically disconnect the network cable, the same thing occurs.

This is broken on Windows 7:

If I disable the network adapter, the ConnectionLost event fires, and I use rmReconnectExecute to re-establish the connection.
If I physically disconnect the network cable, the OnConnectionLost event does not fire. Instead, there is long timeout, and then the application raises two exceptions:
Code: Select all
```
Project myApplication.exe raised exception class EMSError with message 'TCP Provider: The semaphore timeout period has expired.'
```
Code: Select all
```
Project myApplication.exe raised exception class EOLEDBError with message 'Communication link failure'.
```

Evidently Microsoft changed how they handle dropped connections in Windows 7. Do you have any ideas how I can get the OnConnectionLost event to fire on Windows 7 when a physical disconnection has occurred?

AndreyZ · Post by **AndreyZ** » Fri 28 Oct 2011 12:26

Hello,

I cannot reproduce the problem. I tried to unplug my network cable and the OnConnectionLost event fired after attempt to communicate with the server. Please take a look at the following article: http://support.microsoft.com/kb/325487 , it can help you to pinpoint the reason of this problem.

rbrodner · Post by **rbrodner** » Fri 28 Oct 2011 15:45

Every single Windows 7 machine we have tried this on has this problem. Please confirm for me that you were attempting this on a Windows 7 Ultimate, Service Pack 1 operating system.

AndreyZ · Post by **AndreyZ** » Mon 31 Oct 2011 14:47

I've checked this problem on Windows XP Service Pack 2, Windows XP Service Pack 3, Windows 7 Ultimate, and Windows 7 Ultimate Service Pack 1. The OnConnectionLost event handler fired on all of these versions of Windows. Please take a look at the article I gave you in the previous post, it can help you to find the exact reason of this problem.

rbrodner · Post by **rbrodner** » Thu 03 Nov 2011 22:06

Thanks for verifying the OS. I have looked at the article, but I don't think it is really that relevant. When we have used WanEm to do our connection testing, the reconnect fails on Windows 7 when the connection loss is of type icmp-host-unreachable.

I think you may not be reproducing the problem because of client type.

If I use client type prSQL, the reconnect works correctly on both XP and Windows 7. If use the SQL Native Client, type prNativeClient, then unplugging manually fails to reconnect properly on Windows 7.

Try reproducing the problem with the Native Client. Meanwhile, I am going to switch back to prSQL. I won't be able to use query notifications, but I may have a workaround for that.

AndreyZ · Post by **AndreyZ** » Fri 04 Nov 2011 08:05

I've checked both SQL Native Client 2005 and 2008 and there were no problems. Please specify the following:
- the exact version of SDAC. You can learn it from the About sheet of TMSConnection Editor;
- the exact version of your IDE;
- the exact version of SQL server and client. You can learn it from the Info sheet of TMSConnection Editor.

rbrodner · Post by **rbrodner** » Fri 04 Nov 2011 18:04

SDAC Version: 6.0.2 for Delphi 2007
IDE Version: Code Gear RAD Studio 2007 Version 11.0.2902.10471
IDE Installed Updates: December 2007 Update;May08 Help Update
Microsoft SQL Server: 10.00.4000
Microsoft SQL Server Native Client 10.0: 10.50.1600.1

AndreyZ · Post by **AndreyZ** » Mon 07 Nov 2011 13:44

Unfortunately, I still cannot reproduce the problem. I used SDAC 6.0.2 on RAD Studio 2007 11.0.2902.10471 and connected to SQL Server 2008 SP2 (10.00.4000) using SQL Native Client 10 (10.50.1600.1). There were no problems with firing the OnConnectionLost event. It seems that this problem is caused by your network settings.