Irritating SQL 2000/2005 connection problem

[Shawn B.]

Greetings,

Our network environment uses only SQL 2000. We do not have SQL 2005
installed on our network anywhere. Using ADO.NET (SqlCommand and
SqlConnection) to connect to a SQL 2000 database with a connection string
that has worked for 4 years until we migrated to .NET 2.0 we get this error:

-----
A connection was successfully established with the server, but then an error
occurred during the pre-login handshake. When connecting to SQL Server
2005, this failure may be caused by the fact that under the default settings
SQL Server does not allow remote connections. (provider: TCP Provider,
error: 0 - A request to send or receive data was disallowed because the
socket is not connected and (when sending on a datagram socket using a
sendto call) no address was supplied.)
------


A couple things to note: we have no clue where its getting SQL 2005 from.
We do not have SQL Express or 2005 installed. Second, we have many servers
on our network (some for various releases in Dev, Staging, QA, and
production). In trying to connect to any server this problem manifests. In
all cases, SQL is version 2000 with latest SP applied (as well as the Win2k3
and Win2k servers).

More perplexing, when this problem manifests in a WinForms application, it
will only manifest in DEBUG mode but not RELEASE mode. There is nothing in
our code that treats DEBUG and RELEASE differently. Nothing in the project
settings that are out of the ordinary (or that were modified by a human
since the project/solution was created).

When this problem manifests in a WebForms application, it happens in RELEASE
mode. We've been trying to troubleshoot this for 2 weeks now and even have
a support ticket with MS but we're getting no where.

I'm hoping that someone will have some ideas, some things to try to narrow
it down. Microsft doesn't think its a compiler error. I don't know whether
it is or not. The error happens during the SqlConnection.Open() command
instantly.

We have already heavily investigated any potential network issues, network
configurations, network settings, switch/router/firewall
configuration/failures, etc.

We never had this problem with Framework 1.x but only since we've migrated
to 2.0 and its too late to turn back now.

I don't know what I'm asking for, just ideas and suggestions, something to
try.


Thanks,
Shawnh

 

[Guest]

One thing to look into ...shot in the dark....the TCP Provider is
mentioned...if you are authenticating to the server with something other than
SQL server logins it may be the "network library" being used. Named pipes may
be needed, depending on your environment....or something along this line.

Good luck...

 

[Shawn B.]

One thing to look into ...shot in the dark....the TCP Provider is

mentioned...if you are authenticating to the server with something other
than
SQL server logins it may be the "network library" being used. Named pipes
may
be needed, depending on your environment....or something along this line.

We are authenticating via SQL login accounts. This works correctly with
Named Pipes (even though we have them disabled on our servers). In
production, Named Pipes is not an option, we're using a vlan between the web
servers and the sql servers, so it has to be TCP/IP.

Further, when we try the exact same code in VS.NET 2003 (framework 1.1) it
works fine.


However, we'll look into authentication and try to rule that out. Thanks.



Thanks,
Shawn

 

[Shawn B.]

Well, we found the solution to this problem. I'm posting the answer in case
others have a similar problem.

In the project file under "Debug" (C#) is an option: "enable the Visual
Studio hosting process". We have to uncheck that. For some reason, the
hosting process that it produces in DEBUG builds causes problems with
ADO.NET/Sql provider and the way to resolve it is to disable the hosting
process. This is not enabled by default for RELEASE mode and explains why
the application works fine in RELEASE mode. We discovered this problem
after working with Microsoft support for a week or so. Actually, they know
about it and I don't know whether there will be a fix in the upcoming SP.


Thanks,
Shawn