June 11, 2003 at 3:01 pm
Connection Failed:
SQL State '01000'
SQL Server Error: 10061
[Microsoft][ODBC SQL Server Driver][TCP/IP Sockets] ConnectionOpen(Connect()).
Connection Failed:
SQL State '08001'
SQL Server Error: 17
[Microsoft][ODBC SQL Server Driver][TCP/IP Sockets] SQL Server does not exists or access denied
got this when I deleted old dsn and created a new dsn.
June 11, 2003 at 8:31 pm
Try changing your client Net Lib to Named Pipes
MW
Edited by - mworku on 06/11/2003 8:34:40 PM
MW
June 12, 2003 at 10:50 am
Be sure the sql server is running. Also are you using NT authentication or mixed?
Steve Jones
http://qa.sqlservercentral.com/columnists/sjones
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
June 12, 2003 at 10:59 am
I am using mixed, I have created a dsn, I have created the IUSR in SQL and given it permissions. I have not set any folder permissions to IUSR. I just got off the phone with charter (we have a pipeline) to see if the box we have has a firewall configured. He told me that it did not. I am still having trouble with port 1433. Client Network Utility is using 1433 for TCP/IP. When I tried to uncheck dynamic port when I created my dsn it gave me the access denied error above. So I removed that dsn and created a new dsn with the dynamic port checked(under client configuration) and the dsn was created without error. This leads me to believe that port 1433 is not enabled or there are still some permission issues.
Thanks,
Tony
June 12, 2003 at 12:41 pm
The SQL Server may have been created and set to listen to a port other than 1433. Especially if you have virtual servers. We have two virtual servers on one machine and both use different port numbers.
-SQLBill
June 12, 2003 at 2:02 pm
I found some sort of Virtual Server Administration page (Microsoft SharePoint Administrator).
Don't know what it is though!
June 12, 2003 at 4:17 pm
SQLBill may be referring to instances: a default SQL instance (eg. MyServerName) and/or a named SQL instance (eg. MyServerName\MyInstanceName). The default SQL instance listens on port 1433, unless (possibly) for security purposes it has been reconfigured to listen on another. However, leaving UPD 1434 open to resolve port numbers defeats such security measures. A named instance listens on another (NOT Well-Known) port which is dynamically selected the first time it's started.
If you have permissions on the server you can use Server Network utility to see which port it's listening on. Alternatively, you can get a QA or OSQL connection to the server and then from a command prompt do a "NETSTAT -n" and look at the port numbers under Foreign Address for the IP of the server.
A quick and nasty way I often check whether a server is listening on port 1433 is "TELNET Servername 1433". If it goes into a blank unresponsive screen then yes it is listening. If you get a connection failure then no.
Cheers,
- Mark
June 13, 2003 at 11:32 am
mccork,
Thanks for the help. I tried telnet dos command.
ran telnet servername 1433
could not open connection to the host, on port 1433: connection failed
ran telnet servername
cound not open connection to the host, on
port 23: connection failed
June 13, 2003 at 2:38 pm
Use the SQL server network utility wizard and check for
enabled protocols and their properties.
MW
MW
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply