July 21, 2008 at 7:59 am
Hi all,
Had a production issue with a database last night, it has since been resolved.
One of our IT guys told me the application was having a problem connecting to the database, he gav me the name of the database server they were having trouble with and the following error message.
Unable to Connect to SQL Server : 5: 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)
The database it was connecting to is SQL Server 2000 -- So my initial confusion about the error message (stating it was SQL Server 2005) didn't help.
I opened up Enterprise Manager and connected to the database, no problems.
I performed a backup of the database (just in case).
I checked sp_who to see who/how many were connected to the database, no apparent problems.
I googled the error message and came up with the possible solutions that either the database is having trouble resolving to the name, or, the port is blocked by our firewall, or, Windows firewall is blocking it. Checked all, it was fine.
My assumption then was that it was a problem with the application.
Next day, find out that it wasn't this database they were having trouble with, it was a different database that the application ALSO connects to (so there was no problem on that particular database), which was also a SQL Server 2000.
I was wondering if I was pursuing this correctly, or if there were other steps I should have taken that I missed.
Thanks
--------------------------
I long for a job where my databases dont have any pesky users accessing them 🙂
July 21, 2008 at 9:12 am
Seems reasonable to me. I might add that, if I cannot reproduce the problem, I would either go back to the user who originally reported the problem or (if policy disallowed this), kick it back to the help desk or whoever had referred it to me. Best practices for support procedures is to never assume that a problem is fixed or does not exist until/unless the user confirms it.
[font="Times New Roman"]-- RBarryYoung[/font], [font="Times New Roman"] (302)375-0451[/font] blog: MovingSQL.com, Twitter: @RBarryYoung[font="Arial Black"]
Proactive Performance Solutions, Inc. [/font][font="Verdana"] "Performance is our middle name."[/font]
July 21, 2008 at 9:17 am
Thanks for the feedback. i did actually kick it back to the IT guy who passed me the issue in the first place.. so sounds like I was on the right track unless someone else can point out something I missed.
Thanks
--------------------------
I long for a job where my databases dont have any pesky users accessing them 🙂
July 22, 2008 at 12:58 pm
Interesting....
My question is: Why it stated SQL 2005 error msg, but, both the servers are SQL 2000?
July 22, 2008 at 1:00 pm
I wondered that myself.. I was told by the guy who own's the app that its always said 2005 in error messages since they installed VS.NET 2008
--------------------------
I long for a job where my databases dont have any pesky users accessing them 🙂
July 23, 2008 at 7:23 am
I had a similiar problem from my replication that was set up with a different machine for Publisher and Distributor. It had been working fine and all of a sudden it couldn't find the publisher for performing the snap shot.
I could find the Publisher just fine from my desktop machine but when I went to the Distribution machine and tried to ping the publisher machine it could not find it. When I pinged by ip address instead of machine name, it could find it. When I gave this information to my IT people, they were able to resolve it.
Steve
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply