May 11, 2004 at 2:06 pm
Hello,
Well, this is what happens when someone else manages/changes your servers. I may resort to reinstalling after I back things up, but before that I will try this.
No matter how hard I try, I can get 1433 to come back. Something was done (while I was on 2 week holiday) to one of the SQL servers I run. A consultant who is gone and seems to be on holiday as well. Both Named Pipes and TCP/IP are configured and the port/server is not hidden. And yet, no matter what, this server no longer registers 1433 and therefore no TCP connections can be made.
I have gone through everything I can think of in network client util and more, but nothing seems to be wrong. And yet...
Any ideas of where to even start looking at this point, before I re-install?
Thanks
Kat
May 11, 2004 at 2:54 pm
Check in the Server NetWork Utility and in the properties of TCP, check the port that it is configured.
Also, if in the server another aplication/process uses the same port by the time SQL is restarted, then the port won't be available for SQL Server. Check by rebooting the server.
May 11, 2004 at 2:59 pm
Already checked all the basics... 🙁 No luck.
The port is there (in the Server Network Util), and it is not hidden. Also, nothing else has the port... This is simply a strange one.
May 12, 2004 at 10:41 am
Using Enterprise Manager on the server that hosts the SQL Server, expand to the Instance. Right click on the instance and select Properties. On the General Tab, click on the Network Properties button. In the right window there should be TCP/IP. Highlight that and select Properties. What PORT is the instance listening on? Just set your applications to use that port (ODBC connection).
None of my SQL Servers use 1433 due to the Slammer Worm.
-SQLBill
May 12, 2004 at 12:58 pm
Perhaps a firewall was updated somewhere else on your network? Can you port scan your server from another machine and see how it responds.
Dave
Trainmark.com IT Training B2B Marketplace
(Jobs for IT Instructors)
May 13, 2004 at 8:32 am
If you need to find out which port is being used by SQL Server:
On the server, open a command prompt (Start>Run type in cmd and click ok), type netstat -a
then enter. That will give you a list of everthing running and which port is being used (the port number is after the colon). Find which port your SQL Server is LISTENING on and set your connections to use that port.
-SQLBill
May 13, 2004 at 8:48 am
Here is the update...
I had already tried the Enterprise Manager and TCP properties. It is listening on 1433 (or so it says). I had already done netstat -an (always add the "n" to avoid name lookups which can show long delays in the display) and no 1433. I had run nmap from my own machine (linux) to see all the ports/services that are there.
Now, one thing that might give someone a hint -- this is an EPO server (from McAfee) which handles the virus patching to all workstations.
I did try one thing yesterday, but then the EPO services could no long talk to SQL and that was to remove the named pipes and leave only TCP/IP. But since it is apparently refusing to listen on this port, the EPO software would not start. With named pipes at least the local services can talk to the server, but nothing else can.
I know this worked as I had web pages being updated with virus patching info that is in the database previous to the "loaner consultant" that "fixed something". *sigh*
THe next step I will be taking is to build a completely new server for testing. I will install a brand new instance of SQL and see what happens. This is simply too baffling..
Thanks for all the input so far... But 1433 continues to elude me.
Kat
May 13, 2004 at 9:11 am
Just a though, I have done a couple of sql uninstall, save files and then reinstall because we had to remove enterprise edition, it might work the same for you as well. It should not take you more then 1 hr to backup all database, stop sql server, copy all file to different directory, uninstal sql server, reboot, reinstall sql server, service pack, hot fixes, stop sql server, copy the old data file back and start sql server. I think it might be the best way to save your time and bring everything up faster.
mom
May 13, 2004 at 6:22 pm
The netstat -an not showing 1433 means it isn't listening. In the SQL Server error log, do you see any errors about not being able to bind to the port?
K. Brian Kelley
@kbriankelley
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply