views:

38

answers:

1

That's a horrible title, sorry.

Here's the scenario:

WCF Service uses LINQ to get data from a SQL database. Service is deployed on 4 (nearly) identical servers running under IIS. All are talking to the same SQL server on a separate machine.

3 of the 4 servers are working great.

On the 4th server we're getting this

A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)

The exception is thrown the first time that my LINQ DataContext is used to execute a query.

All 4 servers are using the same connection string, defined in their machine.config.

On the problematic server, I am able to connect using SQL Management Studio with the same credentials that are in my machine.config. I have also written a simple command line client that does an ADO.NET connection to the database server using the same connection string. It works.

The same identical code is deployed to all 4 servers, with identical configs.

What could possibly be causing only my client on just the one server to throw this error?

I've done everything I can to rule out the usual suspects (port blocked by firewall, remote access not enabled on SQL Server, using a named SQL instance, etc). I've also checked to see if there any hardcoded connection strings in my code, or elsewhere in the config hierarchy. As best as I can tell that's not the cause.

+1  A: 

We got this working. I don't totally understand the problem, but the gist of it was that the db server didn't have TCP/IP enabled, just named pipes. The 3 servers that were working were able to connect via named pipes. The bad server was not able to use named pipes - I think because it was on a different network (or segment) than the db server.

What I still don't understand was why I was able to use SQL Mgmt Studio to connect from the bad server. If neither TCP/IP nor pipes was available, how was it connecting? Is there some other connection method?

So I'm glad it's working, but a little uncomfortable that I don't completely understand the underlying problem that caused it.

Jason