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.)
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.
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