views:

1148

answers:

9

An error has occurred while establishing a connection to the server. 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: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)

Hello I am new on developing on SQL Server 2005. I've worked for several years with SQL Server 2000, but after doing the usual stuff I do to connect to the server I get this exception on the web server.

There are several links on google that point me to possible solutions, but none of them have solved my problem. I've made changes on a "Surface Area whatever..." dialog (What the hell is that??? Why does SQL Server has changed so much??? It seems so complicated now).

I have ensured that SQL Server 2005 is configured properly to allow incoming connections on the instance of database server. I also have selected Automatic as the Startup type to start SQL Server Browser service automatically every time system starts. And no, there is no firewall running.

I've tried changing the connection string to connect using a port, to connect using the IP, to connect using the instance name...

Nothing seems to work, I'm still getting the same error. Any hint?

Answering the questions that people have made: Yes, I can connect using management studio from a different computer. Yes, I'm sure it's configured to accept local and remote TCP/IP and named pipes. Yes, I restarted the server.

I am using Mixed mode security, which I already enabled. I already enabled the sa user. I am able to connect to the database using a .udl file, and I've checked that my connection string is OK. I can connect to the database using DBArtisan and SQL Server client tools. I can do that both on the server and on a different machine. Even with all that...

The website is still unable to connect.

New update... I've been struggling all day with this problem, and still haven't found out the cause. It seems that the error message I posted is a generic error that .net gives when it's not able to connect. I placed trash on the connection string (typing servers that don't exist) and I still get the same error.

These are some of the connection strings I've used on the server:

connectionString="Integrated Security=SSPI; Data Source=SERVER; Initial Catalog=db; Network Library=DBMSSOCN;"

connectionString="Data Source=SERVER; Initial Catalog=db; User ID=sa; Password=xxxxx;"

connectionString="Data Source=SERVER\MSSQLSERVER; Initial Catalog=db; User ID=sa; Password=xxxxx;"

I tried to register the sql server instance using some strange command, I found that here: http://kb.discountasp.net/article.aspx?id=1041 To do that I used the aspnet_regsql.exe tool. It's still not working...

I also know that the server has the latest version of MDAC installed on it. The only thing that I'm suspicious on is that the server has two Database engines: SERVER and server\sqlexpress

Does that has something to do with the problem?

A: 

Can you connect to the SQL Server via Management Studio from a different machine? This might help you narrow down whether it is the SQL Server configuration or you connection string configuration.

Jeremy Coenen
I can connect using DBArtisan. So I guess that the problem is not on the connection string.
Carlos Kirkconnell
A: 

Recheck the surface area configuration, and make sure TCP/IP connections are allowed.

David Thibault
A: 

This could be many things. The first thing I would check is to make sure you can connect to the server using SQL Server Management Studio. Second, check your connection string to make sure it is correct. Surface area configuration should not apply for local connections.

dotnetengineer
A: 

Try re-installing the latest MDAC on the server. I once had a similar problem and this solved it.

[http://www.microsoft.com/downloads/details.aspx?familyid=6c050fe3-c795-4b7d-b037-185d0506396c&displaylang=en][1]

dotnetengineer
A: 

Based on the error looks like the code is attempting to connect using named pipes, rather than TCPIP. You may actually need to specifically indicate in your connection string that the sql provider should connect using tcpip, so your connection string would look like the below.

Using Integrated Authentication (windows):

Integrated Security=SSPI; Data Source=SERVERNAME; Initial Catalog=DATABASENAME; Network Library=DBMSSOCN;

Using SQL Authentication:

UID=USERNAME; PWD=PASSWORD; Data Source=SERVERNAME; Initial Catalog=DATABASENAME; Network Library=DBMSSOCN;

I've seen something akin to this happen before, where for some reason "named pipes" is used by default as the transport/connection layer, especially since both the web application and sql server are running on the same machine. I generally always use tcpip as the transport, or network library.

Another troubleshooting technique is to use a UDL (or data link file) to troubleshoot the connection. This allows you to switch between connection providers (ODBC, OLEDB, etc) and to set other connection options.

  1. On the desk top of the machine right click and choose new -> text document.
  2. Rename the *.txt file to TestConnect.udl (name doesn't matter just needs to be .udl extension). You should see the icon change from a text file icon to an icon that shows a computer on top of a data grid, or something like that (in other words windows should have an icon for it.).
  3. Now double click the file and you will see a "Data Link Properties" applet appear.
  4. Click the Provider tab, and you will see a list of different connection providers. I'd start by just choosing "Microsoft OLE DB Provider for SQL Server". We can use this to confirm that OLE DB can connect or not.
  5. Click next, and enter the servername or ip address. Select Windows NT Integrated security. (You can always come back and change it to use a sql login.) At this point you can click "Test Connection". If the connection succeeds, then select a database name from the drop down list.
  6. Lastly, if the connection fails, select the "All" tab, and then look for "Network Library" and edit its value, setting it to "DBMSSOCN".
  7. Go back to the connection tab and click "test connection" again.
  8. Repeat steps 4 and 5 this time with the "SQL Native Client" selected.

Hope this helps.

Jon
I tried using the UDL, and I can connect to the database with no problem, but the website keeps being unable to connect.
Carlos Kirkconnell
did you update the web site's connection string to include "Network Library=DBMSSOCN"? Do you still get the same error that references named pipes?
Jon
Try the various troubleshooting steps outlined here:http://blogs.msdn.com/sql_protocols/archive/2007/03/31/named-pipes-provider-error-40-could-not-open-a-connection-to-sql-server.aspx
Jon
A: 

At the prompt does:

osql -E -S

... get you a > prompt ?

I can connect using a .udl file, so I guess that I can also connect using osql
Carlos Kirkconnell
A: 

Did you try specifying the instance name in the connection string? Apparently sql server express, in particular, is finicky about having the instance name.

I've also started to poke around with the SQL Server Configuration Manager. So did you click into "SQL Server 2005 Network Configuration" and then look at "Protocols for InstanceName"? And you enabled TCP/IP and Named Pipes?

Did you also look at the "SQL Native Client Configuration" --> "Client Protocols", and you see that TCP/IP and Named Pipes is enabled there as well?

Using the SQL Server 2005 Surface Area Configuration tool, click the "Surface Area Configuration for Services and Connections", then under "Database Engine" --> "Remote Connections" what is selected? Since it appears that you are attempting to connect using Named Pipes you will need to make sure that "Local and remote connections" and "using both tcp/ip and named pipes" is selected.

As you probably know, once any changes are made, you have to stop and restart the sql server instance via Management Studio (you don't need to reboot the entire machine, although rebooting the entire machine will get you there).

And my last piece of advice. Step away from this for a while, and get your mind off of it for a few minutes. When you dive back in, you may find something you missed or overlooked before.

Jon
+1  A: 

The only thing that I'm suspicious on is that the server has two Database engines: SERVER and server\sqlexpress

I think this is the source of the problem. Which one do you intend to connect to? You need to specify the "instance" you are connecting to.

Assuming you intend to connect to the SERVER instance, you connection string should then look like this (assuming the default instance name):

Data Source=YOURSERVER\MSSQLSERVER; Initial Catalog=db; User ID=sa; Password=xxxxx;

Or for sql express the connection string looks like this: Data Source=YOURSERVER\sqlexpress; Initial Catalog=db; User ID=sa; Password=xxxxx;

Jon
I already tried that and it didn't work... :(
Carlos Kirkconnell
Bummer, I'm stumped now. If this is an option, the next thing I'd try is to remove the SQL Express instance all together (de-install sql express) and consolidate.
Jon
A: 

I fixed the issue that I had with the connection. The problem was on my application. The cause of the issue was that a connection string to the development (instead of the production) database, was hardcoded by one of the dialogs that generates the datasets. This dialog placed the connection string both on the web.config, and on a hidden sourcecode file called "Settings.settings.cs". The problem was solved by fixing the connection string to the correct location.

The error message was totally misleading, but I was able to find that by following all the methods presented on the stack trace.

So if you ever find this error message, there are tons of possible causes. Your first bet is to follow the usual steps for this error, which are checking that the server allows remote and local connections, and restarting the browser service.

If that doesn't work, check the stack trace, look for code that is in your application, put a break point there and explore all the properties on the connection string. At least that's how I solved it.

Carlos Kirkconnell