June 10, 2009 at 12:59 pm
We've migrated all our applications from SQL 2000 to 2005. One of my ASP apps is now getting this error.
Microsoft OLE DB Provider for SQL Server error 80004005
[DBNETLIB][ConnectionOpen (Connect()).]SQL Server does not exist or access denied.
We've ensured remote connections are on and named pipes and tcp/ip are both enabled. Would there be anything in the IIS event log that might tell me what account is being denied access? I have several other .NET apps running so I know both IIS and SQL are running correctly.
Please help - thanks.
June 10, 2009 at 4:24 pm
This is a generic catch-all error. In 99+% of cases it's because the client cannot resolve the name/address of the SQL Server instance: you will nearly always get "logon failure" if it can connect to the server but the logon credentials are wrong.
Just to be certain, try to connect through eg. Query Analyser or Management Studio from a different machine using the same login as the application.
Do your other applications connect to databases on the same instance as the one that's failing? If so the easiest fix would be to change the failing application so it uses exactly the same way of addressing the server/instance as the other applications that are working.
If that is by name use ping from the application server to ensure that the server name can be resolved to the correct IP address. If it doesn't you need to check DNS to resolve the issue.
Assuming you can ping the server then it is an issue either resolving the TCP port under which the target SQL Server instance is running or that one of the ports is blocked. If there is a firewall in between the application and database servers make sure you have the necessary TCP port open to allow the app to connect to the database. Check that the server is using a fixed TCP port for the instance, rather than a dynamic one, and change it to a fixed port if necessary.
The next thing I'd do is to run the Client Network Utility (cliconfg.exe), delete any existing alias for that server/instance (unless you know that it is required for one of the other applications, in which case change this application to use that alias as the server/instance name) then add a new one, specifying TCP/IP and hard-coding the TCP port under which the instance is running (especially if it is going through a firewall).
If your application is using an ODBC alias drop the existing alias and creating a new one. I'd recommend making that new definition using OLE/DB: it's faster than NetLib and NetLib is deprecated.
June 11, 2009 at 2:24 am
You might also want to check the port. The default port is 1433, but you might have changed it during the installation. Or, the previous installation might have been different, and the web app is still using that.
Wayne
Microsoft Certified Master: SQL Server 2008
Author - SQL Server T-SQL Recipes
June 11, 2009 at 9:37 am
Thank you for the replies, I'll see what we can do to test some of these ideas.
This application is very odd. Most of the SQL connections use the connection string in the web.config file - those all work. There is one instance on an include file (.inc) that has the connection string hard coded - that's the one that's failing. The info in the strings is exactly the same.
I was wondering if the accounts that are used for these two connections would be different for some reason? For instance, through the web.config file IIS uses some system account, and through the .inc file it uses IUSR? Just a thought, please let me know if you have any thoughts - thanks.
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply