April 7, 2003 at 7:32 am
Started seeing this message early this morning. Nothing to my knowledge has changed. We can't connect to SQL. We're running SQL2k SP3. Need help.
Error: -2147467259 (80004005); Provider Error: 17 (11)
Error string: [DBNETLIB][ConnectionOpen (Connect()).]SQL Server does not exist or access denied.
Error source: Microsoft OLE DB Provider for SQL Server
Help file:
Help context: 0
April 7, 2003 at 8:14 am
1. Try to ping your server.
2. Make sure SQL Server and Agent services are started.
3. Check your server application and system logs for any errors related.
4. Verify MDAC version on the machines that you can't connect to SQL Server.
5. Check SQL Server authentication Mode.
April 7, 2003 at 8:19 am
Sometimes when you restart SQL Server, and if you are using TCP/IP, the default port of TCP 1433 doesn't open. To check this you can telnet your server with that port. If you can't connect then you must restart Windows instad SQL Server,.
April 7, 2003 at 8:58 am
All--
Thanks for the quick reply. We figured it out. Apparently something did change. The option in SQL server to hide port 1433 was set. But it doesn't play nice with DTS packages within a scheduled job. (All of the jobs that failed invoked DTS via a command line.) We disabled this feature and restarted the server and things started working. This, however, opens another issue i.e. why hiding SQL causes dts to fail when executed from a scheduled job? Thanks for the quick response. I greatly appreciate it. Let me know if you'd like to discuss this new issue.
April 7, 2003 at 9:26 am
Enable the Hide Server option and then you restart the computer that is running SQL Server 2000, the server will no longer respond to broadcasts from clients that are attempting to locate instances of SQL Server on the network.
April 7, 2003 at 9:32 am
I'm told that enabling the hide SQL option changes 1433 to 2433. Is this true? When we enabled it and restarted the system all of the scheduled jobs using DTS run failed. When we disabled and restarted the scheduled jobs worked. We also saw users with ODBC connections faile as well. Has anyone else experienced this problem? What are your thoughts on using the hide server feature feature?
April 7, 2003 at 9:37 am
Check this KB article. http://support.microsoft.com/default.aspx?scid=kb;en-us;308091
April 8, 2003 at 1:03 pm
Read it. But, we're not running multiple instances of sql on the same server. We had some ODBC users denied access because of the hide feature port change (1433 to 2433) but DTS within a job is a mystery. I'm guessing this is either a bug or intentional design.
April 9, 2003 at 6:47 am
Has anyone used the hide server feature? If so, what was the result? Any problems?
April 9, 2003 at 7:01 am
All -- Here is the bug! Hide server should never be enabled with SQL2k SP3!
April 14, 2003 at 1:38 pm
Here is another scenario related to SQL Server 7. A colleague working for some other company ran into a similar problem, and I have been trying to help him out. He said that he rebooted his Windows NT server running SQL Server 7 SP 2 after a long time and now for some reason clients cannot connect to that Server using TCP/IP port 1433. Though they can connect through Multi-protocol. I made him check his firewall rules as well as Server network utility and that was not it. I asked him to make sure TCP/IP on 1433 is enabled. From the command prompt of that box netstat -an ( look for 1433 LISTENING - look to see if any other application on that box is using 1433). Also had him create and try and test a DSN from the box itself and from other boxes on the network. I cannot detect that port when I scan that port using a network scanner either. I asked him to send me the exact error message from the Logs and it said “ Could not set up ListenOn connection'1433' “
Anybody got any ideas that I can pass along to him.
April 14, 2003 at 2:26 pm
Do you see an entry "Using 'SSMSSO70.DLL' version '7.0.xxx' to listen on '1433'" in SQL Server errorlog? Or any error messages?
April 14, 2003 at 2:36 pm
Here is the entire entry in the log:
2003-03-04 08:42:41.04 ods Error: 17826, Severity: 18, State: 1
2003-03-04 08:42:41.04 ods Could not set up ListenOn connection'1433'..
2003-03-04 08:42:41.03 ods Operating system error 10049., 2003-03-04
No reference to - Using 'SSMSSO70.DLL' version '7.0.xxx' in the error logs
Thanks
April 14, 2003 at 2:56 pm
Was this SQL Server upgrade from SQL Server 6.5 to 7.0? Following KB articles may help.
http://support.microsoft.com/default.aspx?scid=kb;en-us;293107
http://support.microsoft.com/default.aspx?scid=kb;en-us;329878
What is the MDAC version? Have you considered apply latest service pack?
April 15, 2003 at 6:45 am
Already checked. Port 1433 is not being used by any other app. Infact any other port that is used gives the same result in the SQL server error logs. Its on SP2 so the second article would not apply. I am not sure what version of MDAC they are on. Prob not the latest. Like I said earlier, its not our Server that is affected. Its a third party server that we use to pull data from. They don't seem to know what the problem is and we have had to come up with an alternative way of pulling data. I want to help resolve their issue so we can go back to using TCP/IP, our prefered method. Thanks for your help.
Viewing 15 posts - 1 through 15 (of 17 total)
You must be logged in to reply to this topic. Login to reply