SQL Server数据库连接失败错误及解决方法

SQL Server数据库连接失败错误及解决方法

在使用SQL Server 的过程中，用户遇到的最多的问题莫过于连接失败了。一般而言，有以下两种连接SQL Server 的方式，一是利用SQL Server 自带的客户端工具，如企业管理器、查询分析器、事务探查器等;二是利用用户自己开发的客户端程序，如ASP 脚本、VB程序等，客户端程序中又是利用ODBC 或者OLE DB 等连接SQL Server。下面，我们将就这两种连接方式，具体谈谈如何来解决连接失败的问题。

一、客户端工具连接失败

在使用SQL Server 自带的客户端工具(以企业管理器为例)连接SQL Server时，最常见的错误有如下一些：

1、SQL Server 不存在或访问被拒绝

ConnectionOpen (Connect())

2、用户'sa'登录失败。原因：未与信任SQL Server 连接相关联。

3、超时已过期。

下面我们依次介绍如何来解决这三个最常见的连接错误。

第一个错误"SQL Server 不存在或访问被拒绝"通常是最复杂的，错误发生的原因比较多，需要检查的方面也比较多。一般说来，有以下几种可能性：

1、SQL Server名称或IP地址拼写有误;

2、服务器端网络配置有误;

3、客户端网络配置有误。

要解决这个问题，我们一般要遵循以下的步骤来一步步找出导致错误的原因。

首先，检查网络物理连接：

ping <服务器IP地址>

或者

ping <服务器名称>

如果ping <服务器IP地址> 失败，说明物理连接有问题，这时候要检查硬件设备，如网卡、HUB、路由器等。还有一种可能是由于客户端和服务器之间安装有防火墙软件造成的，比如ISA Server。防火墙软件可能会屏蔽对ping、telnet 等的响应，因此在检查连接问题的时候，我们要先把防火墙软件暂时关闭，或者打开所有被封闭的端口。

如果ping <服务器IP地址> 成功而ping <服务器名称> 失败，则说明名字解析有问题，这时候要检查DNS 服务是否正常。有时候客户端和服务器不在同一个局域网里面，这时候很可能无法直接使用服务器名称来标识该服务器，这时候我们可以使用HOSTS文件来进行名字解析，具体的方法是：

1、使用记事本打开HOSTS文件(一般情况下位于C:\WINNT\system32\drivers\etc).

2、添加一条IP地址与服务器名称的对应记录，如：

172.168.10.24 myserver

也可以在SQL Server 的客户端网络实用工具里面进行配置，后面会有详细说明。

其次，使用telnet 命令检查SQL Server服务器工作状态：

telnet <服务器IP地址> 1433

如果命令执行成功，可以看到屏幕一闪之后光标在左上角不停闪动，这说明SQL Server 服务器工作正常，并且正在监听1433端口的TCP/IP 连接;如果命令返回"无法打开连接"的错误信息，则说明服务器端没有启动SQL Server 服务，也可能服务器端没启用TCP/IP 协议，或者服务器端没有在SQL Server 默认的端口1433上监听。

接着，我们要到服务器上检查服务器端的网络配置，检查是否启用了命名管道，是否启用了TCP/IP 协议等等。我们可以利用SQL Server 自带的服务器网络使用工具来进行检查。

点击：程序-> Microsoft SQL Server -> 服务器网络使用工具，打开该工具后看到的画面如下图所示：

从这里我们可以看到服务器启用了哪些协议。一般而言，我们启用命名管道以及TCP/IP 协议。

点中TCP/IP 协议，选择"属性"，我们可以来检查SQK Server 服务默认端口的设置，如下图所示：

一般而言，我们使用SQL Server 默认的1433端口。如果选中"隐藏服务器"，则意味着客户端无法通过枚举服务器来看到这台服务器，起到了保护的作用，但不影响连接。

检查完了服务器端的网络配置，接下来我们要到客户端检查客户端的网络配置。我们同样可以利用SQL Server 自带的客户端网络使用工具来进行检查，所不同的是这次是在客户端来运行这个工具。

点击：程序-> Microsoft SQL Server -> 客户端网络使用工具，打开该工具后看到的画面如下图所示：

从这里我们可以看到客户端启用了哪些协议。一般而言，我们同样需要启用命名管道以及TCP/IP 协议。

点击TCP/IP 协议，选择"属性"，可以检查客户端默认连接端口的设置，如下图所示。

该端口必须与服务器一致。

单击"别名"选项卡，还可以为服务器配置别名。服务器的别名是用来连接的名称，连接参数中的服务器是真正的服务器名称，两者可以相同或不同。如下图中，我们可以使用myserver来代替真正的服务器名称sql2kcn-02，并且使用网络库Named Pipes。别名的设置与使用HOSTS文件有相似之处。

通过以上几个方面的检查，错误 1 发生的原因基本上可以被排除。下面我们再详细描述如何来解决错误2。

当用户尝试在查询分析器里面使用sa来连接SQL Server，或者在企业管理器里面使用sa来新建一个SQL Server注册时，经常会遇到如图2 所示的错误信息。该错误产生的原因是由于SQL Server使用了"仅Windows"的身份验证方式，因此用户无法使用SQL Server的登录帐户(如sa )进行连接。解决方法如下所示：

1、在服务器端使用企业管理器，并且选择"使用Windows 身份验证"连接上SQL Server;

2、展开"SQL Server组"，鼠标右键点击SQL Server服务器的名称，选择"属性"，再选择"安全性"选项卡;

3、在"身份验证"下，选择"SQL Server和Windows "。

4、重新启动SQL Server服务。

在以上解决方法中，如果在第 1 步中使用"使用Windows 身份验证"连接SQL Server 失败，那么我们将遇到一个两难的境地：首先，服务器只允许了Windows 的身份验证;其次，即使使用了Windows 身份验证仍然无法连接上服务器。这种情形被形象地称之为"自己把自己锁在了门外"，因为无论用何种方式，用户均无法使用进行连接。实际上，我们可以通过修改一个注册表键值来将身份验证方式改为SQL Server 和Windows 混合验证，步骤如下所示：

1、点击"开始"-"运行"，输入regedit，回车进入注册表编辑器;

2、依次展开注册表项，浏览到以下注册表键：

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\MSSQLServer]

3、在屏幕右方找到名称"LoginMode"，双击编辑双字节值;

4、将原值从1改为2，点击"确定";

5、关闭注册表编辑器;

6、重新启动SQL Server服务。

此时，用户可以成功地使用sa在企业管理器中新建SQL Server注册，但是仍然无法使用Windows身份验证模式来连接SQL Server。这是因为在SQL Server 中有两个缺省的登录帐户：BUILTIN\Administrators 以及<机器名>\Administrator 被删除。要恢复这两个帐户，可以使用以下的方法：

1、打开企业管理器，展开服务器组，然后展开服务器;

2、展开"安全性"，右击"登录"，然后单击"新建登录";

3、在"名称"框中，输入BUILTIN\Administrators;

4、在"服务器角色"选项卡中，选择"System Administrators" ;

5、点击"确定"退出;

6、使用同样方法添加<机器名>\Administrator 登录。

以下注册表键

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\MSSQLServer\LoginMode

的值决定了SQL Server将采取何种身份验证模式。该值为1，表示使用Windows 身份验证模式;该值为2，表示使用混合模式(Windows 身份验证和SQL Server 身份验证)。

看完如何解决前两个错误的方法之后，让我们来看一下如图 3 所示的第三个错误。

如果遇到第三个错误，一般而言表示客户端已经找到了这台服务器，并且可以进行连接，不过是由于连接的时间大于允许的时间而导致出错。这种情况一般会发生在当用户在Internet上运行企业管理器来注册另外一台同样在Internet上的服务器，并且是慢速连接时，有可能会导致以上的超时错误。有些情况下，由于局域网的网络问题，也会导致这样的错误。

要解决这样的错误，可以修改客户端的连接超时设置。默认情况下，通过企业管理器注册另外一台SQL Server的超时设置是4 秒，而查询分析器是15 秒(这也是为什么在企业管理器里发生错误的可能性比较大的原因)。具体步骤为：

1、在企业管理器中，选择菜单上的"工具"，再选择"选项";

2、在弹出的"SQL Server企业管理器属性"窗口中，点击"高级"选项卡;

3、在"连接设置"下的"登录超时(秒)"右边的框中输入一个比较大的数字，如20。

查询分析器中也可以在同样位置进行设置。

二、应用程序连接失败

以上的三种错误信息都是发生在SQL Server 自带的客户端工具中，在应用程序中我们也会遇到类似的错误信息，例如：

Microsoft OLE DB Provider for SQL Server (0x80004005)

[DBNETLIB][ConnectionOpen (Connect()).]Specified SQL server not found.

Microsoft OLE DB Provider for SQL Server (0x80004005)

用户'sa' 登录失败。原因: 未与信任SQL Server 连接相关联。

Microsoft OLE DB Provider for ODBC Drivers 错误'80004005'.

[Microsoft][ODBC SQL Server Driver]超时已过期.

首先，让我们来详细看以下的示意图来了解一下使用ODBC 和使用OLE DB 连接SQL Server 有什么不同之处。

从上图中，我们可以看出在实际使用中，应用程序创建和使用各种ADO 对象，ADO 对象框架调用享用的OLE DB 提供者。为了访问SQL Server 数据库，OLE DB 提供了两种不同的方法：用于SQL Server 的OLE DB 提供者以及用于ODBC 的OLE DB 提供者。这两种不同的方法对应于两种不同的连接字符串，标准的连接字符串写法如下所示：

1、使用用于SQL Server 的OLE DB 提供者：

使用SQL Server 身份验证：

oConn.Open "Provider=sqloledb;" & _

"Data Source=myServerName;" & _

"Initial Catalog=myDatabaseName;" & _

"User Id=myUsername;" & _

"Password=myPassword"

使用Windows 身份验证(信任连接)：

oConn.Open "Provider=sqloledb;" & _

"Data Source=myServerName;" & _

"Initial Catalog=myDatabaseName;" & _

"Integrated Security=SSPI"

2、使用用于ODBC 的OLE DB 提供者(不使用ODBC 数据源)：

使用SQL Server 身份验证：

oConn.Open "Driver={SQL Server};" & _

"Server=MyServerName;" & _

"Database=myDatabaseName;" & _

"Uid=myUsername;" & _

"Pwd=myPassword"

使用Windows 身份验证(信任连接)：

oConn.Open "Driver={SQL Server};" & _

"Server=MyServerName;" & _

"Database=myDatabaseName;" & _

"Trusted_Connection=yes"

3、使用用于ODBC 的OLE DB 提供者(使用ODBC 数据源)：

oConn.Open "DSN=mySystemDSN;" & _

"Uid=myUsername;" & _

"Pwd=myPassword"

如果遇到连接失败的情况，我们只要按照一中所示的方法，结合程序中的连接字符串进行检查，基本都能得到解决。另外，还有以下几个要注意的地方：

1、配置ODBC 数据源时，点击"客户端"配置选项可以让我们指定连接使用的网络库、端口号等属性，如下图所示：

2、如果遇到连接超时的错误，我们可以在程序中修改Connection 对象的超时设置，再打开该连接。例如：

<%

Set Conn = Server.CreateObject("ADODB.Connection")

DSNtest="DRIVER={SQL

Server};SERVER=ServerName;UID=USER;PWD=password;DATABASE=mydatabase"

Conn. Properties("Connect Timeout") = 15 '以秒为单位

Conn.open DSNtest

%>

3、如果遇到查询超时的错误，我们可以在程序中修改Recordset 对象的超时设置，再打开结果集。例如：

Dim cn As New ADODB.Connection

Dim rs As ADODB.Recordset

. . .

cmd1 = txtQuery.Text

Set rs = New ADODB.Recordset

rs.Properties("Command Time Out") = 300

'同样以秒为单位，如果设置为0 表示无限制

rs.Open cmd1, cn

rs.MoveFirst

. . .

三、小结

本文针对大部分用户在使用SQL Server 过程中常见的连接失败的错误，重点讨论了在使用SQL Server 客户端工具以及用户开发的应用程序两种情况下，如何诊断并解决连接失败的错误。看过本文以后，相信每一个读者都会对SQL Server 的连接工作原理、身份验证方式以及应用程序开发等有一个较为全面

而深入的连接。本文中所有的测试或者示例均在Windows 2000 Advanced Server + SQL Server 2000 企业版上通过。

如何打开1433端口的解决方法

这篇文章主要针对Win2003系统安装SQL Sever2000后1433端口未开放，如何打开1433端口的解决方法。

用了几年的Windows2003和SQL Server2000了，不过这个问题倒是头次遇到。最近调试一个JSP+SQL2000WEB程序遇到个现象，在Win2003简体中文服

务器版上安装SQL Server2000，默认安装，一切正常，但是在安装完成后Tomcat运行正常，JSP程序却无法连接SQL2000数据库，查看端口，1433端口居然未开放，当然

更不用说远程连接了。

一般分析的都是这样：

1、sql server服务没有启动；

检查服务启动，重新启动服务故障依然。

2、修改了端口号；

打开网络实用工具，检查启用的协议中有TCP/IP协议，查看端口，是1433没错。

3、客户端实用工具作了改动；

打开客户端实用工具，检查协议端口正常，重新创建一个别名，依然不行。

4、安装的问题；

怀疑安装步骤有问题。遂卸载重装，一切默认，故障依然。

5、安装版本的问题；

查看安装光盘，是久经考验的安装盘，应该不会出问题。

6、系统的问题；

也看不出有什么其它的问题，难道是系统的问题？不过重装系统可太过麻烦，还是先想想其

它的办法，看能不能

找到问题所在。

检查系统日志，这个应该是一个比较好的习惯。仔细翻了一遍重新安装后的日志，赫然发现如下内容：

您运行的Microsoft SQL Server 2000 版本或Microsoft SQL Server 2000 Desktop Engine (也称为MSDE) 和

Microsoft Windows Server 2003 家族使用时存在已知的安全弱点。为了减少计算机被某些病毒的攻

击，Microsoft SQL Server 2000，MSDE 或两者的TCP/IP和UDP 网络端口被禁用。要启用这些端口，您必须

从https://www.360docs.net/doc/994975918.html,/sql/downloads/default.asp 或https://www.360docs.net/doc/994975918.html,/china/sql/downloads/default.asp

安装一个修补程序，或Microsoft SQL Server 2000 或MSDE 的最新服务包。

https://www.360docs.net/doc/994975918.html,/downloads/details.aspx?familyid=8E2DFC8D-C20E-4446-99A9-B7F0 213F8BC5&displaylang=en

有关更多信息，请参阅在https://www.360docs.net/doc/994975918.html,/fwlink/events.asp 的帮助和支持

终于找到问题了，原来是Windows的一个小小的安全考虑。那么为什么以前就没遇到过呢，原来搞惯安全的人，安

装好sql以后，在使用前一定会先修补漏洞，所以一直未注意过这个问题。看来什么样的习惯都会有一些弊端！

既然找到问题就简单了，立刻到微软网站：https://www.360docs.net/doc/994975918.html,/downloads/details.aspx? displaylang=zh-cn&FamilyID=8E2DFC8D-C20E-4446-99A9-B7F0213F8BC5

下载SP4的“数据库组件（下载文件：SQL2000-KB884525-SP4-x86.EXE）”

安装SQL Server SP4后，浏览器地址栏测试https://www.360docs.net/doc/994975918.html,一切正常。

附：

远程连接sql server 2000服务器的解决方案

解决方案步骤：

一看ping 服务器IP能否ping通。

这个实际上是看和远程sql server 2000服务器的物理连接是否存在。如果不行，请检查网络，查看配置，当然得

确保远程sql server 2000服务器的IP拼写正确。

二在Dos或命令行下输入telnet 服务器IP 端口，看能否连通。

如telnet 202.114.100.100 1433

通常端口值是1433，因为1433是sql server 2000的对于Tcp/IP的默认侦听端口。如果有问题，通常这一步会出问

题。通常的提示是“……无法打开连接,连接失败”。

如果这一步有问题，应该检查以下选项。

1 检查远程服务器是否启动了sql server 2000服务。如果没有，则启动。

2 检查服务器端有没启用Tcp/IP协议，因为远程连接（通过因特网）需要靠这个协议。检查方法是，在服务器上

打开开始菜单->程序->Microsoft SQL Server->服务器网络实用工具，看启用的协议里是否有

tcp/ip协议，如果

没有，则启用它。

3 检查服务器的tcp/ip端口是否配置为1433端口。仍然在服务器网络实用工具里查看启用协议里面的tcp/ip的属

性，确保默认端口为1433，并且隐藏服务器复选框没有勾上。

事实上，如果默认端口被修改，也是可以的，但是在客户端做telnet测试时，写服务器端口号时必须与服务器配

置的端口号保持一致。如果隐藏服务器复选框被勾选，则意味着客户端无法通过枚举服务器来看到这台服务器，

起到了保护的作用，但不影响连接，但是Tcp/ip协议的默认端口将被隐式修改为2433，在客户端连接时必须作相

应的改变。

4 如果服务器端操作系统打过sp2补丁，则要对windows防火墙作一定的配置，要对它开放1433端口，通常在测试

时可以直接关掉windows防火墙（其他的防火墙也关掉最好）。

5 检查服务器是否在1433端口侦听。如果服务器没有在tcp连接的1433端口侦听，则是连接不上的。检查方法是在

服务器的dos或命令行下面输入netstat -a -n 或者是netstat -an，在结果列表里看是否有类似tcp 127.0.0.1

1433 listening 的项。如果没有，则通常需要给sql server 2000打上至少sp3的补丁。其实在服务器端启动查询

分析器，输入select @@version 执行后可以看到版本号，版本号在8.0.2039以下的都需要打补丁。

如果以上都没问题，这时你再做telnet 服务器ip 1433 测试，将会看到屏幕一闪之后光标在左上角不停闪动。恭

喜你，你马上可以开始在企业管理器或查询分析器连接了。

三检查客户端设置

程序->Microsoft SQL Server-> 客户端网络使用工具。像在服务器网络实用工具里一样，确保客户端tcp/ip协议

启用，并且默认端口为1433（或其他端口，与服务器端保持一致就行）。

四在企业管理器里或查询分析器连接测试

企业管理器->右键SQlserver组->新建sqlserver注册->下一步->写入远程IP->下一步-> 选Sqlserver登陆->下一

步->写入登陆名与密码（sa,password）->下一步->下一步->完成

查询分析器->文件->连接->写入远程IP->写入登录名和密码（sa,password）->确定

通常建议在查询分析器里做，因为默认情况下，通过企业管理器注册另外一台SQL Server 的超时设置是4秒，而查

询分析器是15秒。

修改默认连接超时的方法：

企业管理器->工具->选项->在弹出的”SQL Server企业管理器属性”窗口中，点击”高级”选项卡->连接设置->在登

录超时（秒）后面的框里输入一个较大的数字

查询分析器->工具->选项->连接->在登录超时（秒）后面的框里输入一个较大的数字

通常就可以连通了，如果提示错误，则进入下一步。

五错误产生的原因通常是由于SQL Server使用了”仅Windows”的身份验证方式，因此用户无法使用SQL Server的

登录帐户（如sa ）进行连接。解决方法如下所示：

1 在服务器端使用企业管理器，并且选择”使用Windows 身份验证”连接上SQL Server。

2 展开”SQL Server组”，鼠标右键点击SQL Server服务器的名称，选择”属性”，再选择”安全性”选项卡。

3 在”身份验证”下，选择”SQL Server和Windows “。

4 重新启动SQL Server服务。（在dos或命令行下面net stop mssqlserver停止服务，net start

mssqlserver启动服务，也是一种快捷的方法）。

注：在连接本地服务器时，通常使用的是命名管道协议（在服务器网络实用工具里可以看到启用的协议有这个）

，默认端口是445，因此在本地能连通是不能说明什么问题的，连接远程服务器是完全不同的协议）。