Sunday, February 19, 2012

Framework 1:1 net

If you connect to a server and open a query in SQL Managment studio (2005) and looses connection and then regain the connection, when you try to run the query it gives me a "TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host."

This happens against both 2005 and 2000 servers.

If I re-run the query it works.

However, this happens in our VB.NET app as well for clients with Wireless connections.

So, something has changed in Framework 2.0 regarding this, does anyone know how to tell the client to not throw this error and just try connecting the server instead which will work?

Hi,

The SqlClient provider does not retry operations if the underlying connection is "broken" (e.g. closed by the server or by a glitch in the network). SQL Server Management Studio retries by trying to open the connection again.

One factor that affects this behavior is whether or not you have connection pooling enabled. Did you include "pooling=false" in your connection string?

This behavior should not have changed from 1.1 to 2.0. Did your 1.1 application behave differently? What error did you get (if any) on 1.1?

Pablo Castro
Program Manager - ADO.NET Team
Microsoft Corp.|||I have not changed anything from 1.1 to 2.0.
(its a 1.1 converted project to 2.0)

No, I did not get any errors like this in 1.1

I dont have Pooling=False, Neither do I want it that way (large app with tons of connections).

as stated it happens BOTH in Sql Management Studio as well as in any VB.NET app, it happens on several diffrent companies on diffrent continents, against diffrent SQL Servers.

VPN Clients, WIFI Clients are hit hardest (they have tiny drops in connections often)|||Bumping this.

Any resolution yet?

Basically, I cannot run any long running queries on computers with SQL Management Studio + Framework 2.0 installed over VPN, Not even in the OLD Query Analyzer anymore(diffrent error, same meaning).

However, on my untouched laptop, that has the old SQL Server Client Tools installed, it works fine on the same VPN connection.

Even on LAN it happens quite frequently, I got my app on about 150 clients, they catched this error about 40 times today.|||This looks really weird. I'll talk to a few other folks in the protocols team to see if I get more ideas to help you out.

There is one bit that particularly gets my attention: the OLD query analyzer uses the old native data-access stack; the SQL Server 2005 setup, or the VS 2005 setup, do not touch any of those bits at all. So, if you're getting the same behavior from the old query analyzer, that may indicate that there was something else that changed and may be causing this glitch. Do you get failures in QA as often as you get with the other clients? What error do you get in the QA case?

I'll reply again to this thread once I have more details or have someone do it.

Regards,
Pablo Castro
Program Manager - ADO.NET Team
Microsoft Corporation|||Hi Fredrik,

It appears that Sqlclient grabs a connection from the pool that has already been closed because of a network error and reports an error when it tries to write to the socket. I can't understand why the 1.1 framework would be less susceptible to these network errors than the 2.0 framework. Would you be able to take a client-side trace that captures the error and send it to me along with the server's error log? You can email me the files at ilsung@.microsoft.com. The instructions for setting up the trace are here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnadonet/html/tracingdataaccess.asp . Also, if you know of a way for us to repro this, that would be great.

Thanks,

Il-Sung Lee
Program Manager, SQL Server Protocols
Microsoft Corp.

This posting is provided "AS IS" with no warranties, and confers no rights.|||I will test the tracing on my home computer which is connected over VPN.

However, Reproducing it in 2.0 enviroment is easy.

Open a SQL Query in SQL Management studio to a server.

Enter a simple query, Run the query, when its completed, disable the network connection, and immediatly enable it again, re-run the query when the network is back up again and you will get the error:

A transport-level error has occurred when sending the request to the server. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)


- Fredrik|||The link you gave refers to Beta 1, is there a updated document for the release version of Framework 2.0?|||I just received this same error today in our production environment. Had not appeared in dev, test or uat. Our application was built in asp.net 2.0 beta 2 and later upgraded to RTM. Besides changing pooling, any suggestions on how to prevent this?|||

If I remember correctly, the same procedure should work for RTM bits. Is it not working for you?

Thanks,
Pablo Castro
Program Manager - ADO.NET Team
Microsoft Corporation

|||

No, I did not get the debug trace function to work, it simply dont dump any data, dont know why.

Anyway.

I found a setting in the SQL Configuration Manager, on TCP/IP Protocol (native) there is KeepAlive and KeepAliveInterval that I am testing a little with.

I sat those settings to zero, eg no keepalive checking I guess, will see how that turns out.

|||Please let everyone know how this goes. I'm having the exact same issue with my application. Thanks!|||

So far 100% success, I left my app running yesterday, and it hadnt crashed still today, one day later. Before the change it only took about 10 minutes on my WiFi before I got a error.

Question is how you can change those values for clients only have .NET framework 2.0 installed (there is no registry entry for that one pre-defined). Registry entry is only present on those clients that have SQL 2005 Client tools installed.

I gonna look a little further with Regmon later this week and see if its just enough to create the registry entry on a "normal" client.

|||

I get the same error. It even occurs between my sql server management studio and the sql instance on the network.

The client has the release version while the sql instance is sql server 2005 beta2. Could this be the issue?

Error connecting to SQLSERVER1\ANINSTANCE. Err: A connection was successfully established with the server, but then an error occurred during the login process. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)

This is a project i converted from 1.1 to 2.0.

The old saved 1.1 project connects without any problems.

It really looks like a framework 2.0 issue.

|||

It would be good if you could try this against a final version of SQL Server. The fact that the beta 2 server is dropping the connection during login is not that surprising, it may be due to a protocol version mismatch detected during the login handshake.

So I wouldn't consider this and the other issue discussed in this thread to be the same thing.

Pablo Castro
Program Manager - ADO.NET Team
Microsoft Corporation

No comments:

Post a Comment