Same client as yesterday, but new problem.
Today, they finally got the new parts they needed to get their SQL server back up and running. Which was the main problem that caused yesterday’s question. Only, the web server(s) could not connect to the SQL server.
So, of course, the client had checked all the obvious stuff before they called me, and when they finally called me, I checked all the obvious stuff. Everything looked like it was configured just the same as it was two days ago. What they heck could be the problem?
Well, the next obvious test is can I connect to the same IP address when I’m on the computer that the database is on. ie, can the sql server computer connect to the sql server using the same settings we are trying to use from the outside.
The answer to that question was "No."
But why? Now, it’s time for some serious tracking. So, here’s what I did.
First, can I telnet to localhost using the port that sql is connected on?
Yep. That works.
Can I connect using telnet to the IP address and port number?
How about the other network cards?
Yep the other cards and IP addresses work.
So, then I asked, "Has anyone rebooted this computer yet? Or at least restarted the SQL server?"
No one had. So, we restarted the SQL service and everything magically started working.
Moral to this story. When something isn’t working, first, try a reboot.
BTW, you can track down just about any connection problem to anything that uses TCP, by using telnet. Get into the console window and type:
telnet serverNameOrIpAddress portNumber
where serverNameOrIpAddress is the actual server you want to test and portNumber is the port the service is listening on. You’ll get an error message if you can’t connect. Otherwise, depending on the service, you’ll either get a blank screen or you’ll get some response from the server.