I have a SQL Server instance that is throwing the "Named Pipes Provider" error, code 40. I know that this is a relatively common error on new installs and there's a convoluted process to fix it. However, the odd part of this error for me is that (1) it only happens intermittently and (2) it only happens with my ASP.NET application. I have other apps that are accessing this server just fine without any errors.
I came across a vague reference to this error happening when your connection string is part of the ASPX code (as opposed to the web.config) and that doesn't make sense but it's the only option I could come up with. Anyone else seen this?
Sounds like a security context issue? How is the asp.net application accessing the sql server? Integrated windows security or sql security? If the earlier check that the identity of the application (asp.net process) which is defined by the Application Pool identity has login rights on the DB.
From http://blogs.msdn.com/b/sql_protocols/archive/2007/03/31/named-pipes-provider-error-40-could-not-open-a-connection-to-sql-server.aspx :
Summary, give checklist:
Is your target server started?
Is your target server listening on NP? Which Pipe?
Has your client enabled NP? Use the same pipe to connect as Server?
Are you making local connection? If so, what is the instance, default or remote?
Did you put correct instance name in the connection string? Remember, Sqlexpress is a named instance.
Did you enable remote connection? Firewall? IPSec? "File and Printer Sharing" opened? Can access server?
Can you make basic connection by using or \? Use sqlcmd or osql.
Related
I'm new to IIS/ASP .Net development, my application is using connection string which are declared to my web.config.
Now I read/heard that I can use IIS App Pool Identities to use instead of web.config.
Here's what I did:
I've deleted my connection string from my web.config
setup my app pool Identity property -> (Identity = ApplicationPoolIdentity)
Added my connection string declared/within the App Site Connection Strings under "Custom" like "Data Source=sql...blah;Initial Catalog=dbname;Integrated Security=False;Persist Security Info=False;User ID=MyDBUserName;Password=MyPassword;Connect Timeout=60;Encrypt=False;Current Language=English;"
It works as far as I know, but my question is, is this really how you configure it?
I was under the impression that you could use some variable (username, pass, dbname..etc), declared it on your web.config and binds it thru your app pool identities but I cannot find any article regarding that.
Thank You
You can set the user that the app-pool runs under. All that does is make the app-pool think that the user is some particular user who is logged on to the server.
This tends to NOT effect your database code, since you STILL need to tell your code what database to use. Even if your host computer and network is say using a domain controller, and you using windows logons to consume sql server. Your .net code behind will WILL need some connection string to specify the database and server anyway. And you having added that user under app-pool identify (I assume this one):
Well, now that "user" is for your file and network rights. So, that user can say be restricted to some set of folders - maybe a another server with large number of documents.
Added my connection string declared/within the App Site Connection Strings under "Custom"
Yes, and that puts the connection string in web.config - if you check the web config after doing above, you should see that string in web.config.
So, in theory, in your code, you can connect to the database server - and your app-pool user will be used, but you STILL have a connection string - what database, what server, etc. still needs to be defined (and used in your code). I mean, say desktop with windows authentication to SQL server does not get you off the hook as having a defined connection string some place to use. While the user might be running in the context of the "defined" app-pool user, you still need some place to store and eventually use some connection string. So, the fact of defining what user in app pool the code behind will run as? You still need a connection string and the connection string you use to the database would not be stored, nor come from app-pool settings anyway.
I am building a website using asp.net MVC. I have two connection strings in the web.config, one for local db and one for the server db. I am testing my work on local and then put it on the server. the server connection string (user name and password) is also in the web.config. Tomorrow when I sell the product, I want to make sure I don't give this web.config to the clients. but It can happen by mistake. How can I prevent this?
My suggestion would be to use one of two methods:
A ConnectionStrings.config or a Web.Config transform. As usual there are pros and cons for both.
Using a separate config file for connection strings
Each developer can have a local copy of their connection strings
ConnectionStrings can be marked to ignore and never committed to source control
However
- Requires each client/developer to be individually managed
Web.config transforms
Each connection string/build configuration can be source controlled
Requires publish of application rather than just a build
However
Can become difficult to maintain with large numbers of transforms.
Personally I prefer having a ConnectionStrings.config - I don't like having production credentials in source control. It also has the nice side effect of giving a build error if you've forgotten it so you can't leave them out by mistake.
Don't use user name and password in the connection string, but use integrated security.
Instead of this.
User ID=****; Password=****;
Use this.
Integrated Security=true;
And make sure your logon user has access to the local database. And the IIS server has access to the server database.
See here for configuring IIS to be able to access SQL Server.
First of all, we have a MVC web application which uses NHibernate (version 3) and an Oracle 11g database.
The application is working, but when we publish in the production server a curious scenario happens:
The user access the application and perform a task, for example, select a link into the Menu.
The user waits a couple of minutes (2-3 minutes).
The user perform another task, for example, reload the same page or select another link into the Menu.
The application fails with a ORA-12571: TNS:packet writer failure exception.
The user just refresh the error page, the application works.
The first thing we tried to do was to isolate the problem, so we published the application into another server with the exactly same configuration:
Same binaries, of course.
Same Oracle x64 client version, even the minor version.
Same Windows Server 2008 version with IIS 7.5.
Same IIS configuration (we compared the windows/system32/inetsrv/config files using WinMerge).
Accessing the same production database.
And for our surprise we couldn't reproduce the problem.
Please, someone have a clue of what is going on?
The problem is related to the connection pool of the server's oracle client. It seems that it is delivering invalid connections to the web application, while in the other servers it does not happens.
The solution is not very interesting, but putting the Validate Connection = True inside the connection string resolved the issue. I am aware of the performance penalty of this, but I am out of options.
PS: using this flag, each connection is validated by the connection pool service before delivering it for the client application. This is not very nice, since a database round-trip will happen for every connection request.
The setup: 2 web servers and a seperate state server
I have two production web servers in a load balanced configuration. The ASP.NET web app they host shares state (like a web farm) using this line in their web.configs:
<sessionState mode="StateServer" stateConnectionString="tcpip=9.9.9.9:42424" cookieless="false" timeout="60"/>
9.9.9.9 is the IP of the machine the asp.net session state service is running on (ok it's not 9.9.9.9 really, changed to protect the innocent). It's a third machine (the database server, actually.
It worked fine until...
The error: website down!
Suddenly the site went down, just showing a generic asp.net error page ('turn custom errors off to see this error' or whatever).
The app's log recorded the actual error message:
An unhandled exception occurred Unable to make the session state request to the session state server. Please ensure that the ASP.NET State service is started and that the client and server ports are the same. If the server is on a remote machine, please ensure that it accepts remote requests by checking the value of HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\aspnet_state\Parameters\AllowRemoteConnection. If the server is on the local machine, and if the before mentioned registry value does not exist or is set to 0, then the state server connection string must use either 'localhost' or '127.0.0.1' as the server name.
So it appears that the web app was unable to contact the state server (9.9.9.9).
I "tried turning if auf and then onnegen" - restarting the state server fixed the problem.
Why?
I really want know what happened and why so I can prevent it happening again.
So far all I have are two theories:
A windows update, to .net framework 4, was applied around that time on the state server. So maybe the update did something to the asp.net state service? The windows event viewer showed that .net 4 had logged a warning around then:
Updates to the IIS metabase were aborted because IIS is either not installed or is disabled on this machine. To configure ASP.NET to run in IIS, please install or enable IIS and re-register ASP.NET using aspnet_regiis.exe /i.
Some kind of temporary network problem between the prod web sites and the state server? They do sit right next to each other in the same physical rack though.
??? Any other ideas, anyone?
Anyone seen this before, or able to correct me on anything?
Has this happened since? The easy answer is that the problem was with the db server, not the web app. Are there any relevant errors in the log on the db server?
The fact that both apps threw an error indicates that a common resource was the problem. We chased a similar issue for a good solid week awhile back, and eventually found a faulty fiber channel gadget. (that's below my OSI level, not sure about the details).
Start–> Administrative Tools –> Services
Right-click over the ASP.NET State Service and click “start”
It is working fine We need to follow the steps
Had a similar issue before when our Infrastructure team tried sneaking in an install of 3.5 when they forgot to install it on our Production box. Not bouncing a server after a framework update is just going to cause all kinds of weird problems.
We've got a web system running SQL Server 2005 for the back end, and ASP.Net for the front end (using .net 2.0).
Every now and then, the system barfs out the error in the title: 'SQLOLEDB' failed with no error message available, result code: E_FAIL(0x80004005).
The web system runs just fine 24/7, and then every now and then will toss this out on a select or some such. I've tried re-running the exact select that throws the error, but (of course) it works fine when I do it. And, to answer the obvious follow-up question, no we haven't done any code changes or upgrades to speak of lately.
Has anyone ever run into this before? Nosing around on google seems to only turn up situations where Access has some kind of file issue (permissions, missing data file, etc.)
Firstly, it's probably not SQL Server throwing out the error, and if it is, it's probably not while running the SQL statement itself, but if it is, it's almost certainly going to be peculiar to a login that doesn't have permissions, not the SQL command itself.
The 0x80004005 error is a general permissions failure, and it can occur in just about anything, but it's most likely to be in another layer.
I've seen it in authentication when the account the application is running under does not have access to the network to open a connection to the SQL Server. The SQL Server never even sees the request, but the client will say that the server cannot be found.
If it's intermittent, that could point to an intermittent domain controller issue, but that would depend on how your Windows Servers and Active Directory are set up, and how your application is connecting to SQL Server.
To solve this one, your netadmins will need to really know their Windows logging functionality and track it down for you.