那天，我正准备连我们那个老系统后台的数据库，结果，怎么搞都连不上！屏幕上就跳那么一句“连接失败”，没头没脑的，真是让人头大。我当时就挠头了，这不经常用的嘛怎么突然就掉链子了？

遇到问题从来不会直接放弃，尤其这种老伙计，总觉得它还能抢救一下。第一个念头就是，是不是我密码输错了？手滑了？赶紧又敲了一遍，结果还是老样子，连不上。这下我就知道，不是我手残的问题了。

检查服务器端情况

我立马就想到了，是不是数据库服务自己挂了？毕竟SQL Server 2000这老东西，偶尔也会犯点小脾气。我赶紧摸到那台放数据库的机器，打开那个“服务”管理界面。我记得一般就是“SQL Server (MSSQLSERVER)”这个服务，得看看它是不是“已启动”状态。我一看，好家伙，果然停着！我心里暗骂一句，这服务又睡着了。赶紧点鼠标右键，选了“启动”。等了一会儿，状态变成了“已启动”。心里一喜，想着这下总该好了？结果回到自己电脑上一试，还是连不上！我这脸当时就拉下来了，白高兴一场。

那既然服务起来了还不行，我就得考虑别的了。我记得以前碰到过网络协议没开的情况。SQL Server 2000那时候，有俩主要协议，一个是TCP/IP，一个是命名管道（Named Pipes）。我赶紧去找到那个“SQL Server网络实用工具”。这玩意儿一般在开始菜单里找，或者直接搜“”。点开一看，我去，那“已启用协议”里面，就剩下个“共享内存”和“VIA”了，最重要的TCP/IP和命名管道都跑到“已禁用协议”那边去了。我当时就懵了，谁给它禁用了？赶紧把TCP/IP和命名管道都选上，“启用”！然后一路确定，退出来。

协议开了，我还得重启一下SQL Server服务，让它生效。又回到服务管理界面，把“SQL Server (MSSQLSERVER)”服务先“停止”，再“启动”一次。这来来回回折腾了两三趟，想着这回总该成了？结果，还是不行！我简直要吐血了，这到底是闹哪样？

我就开始怀疑是不是认证模式的问题。SQL Server 2000有时候默认是“Windows身份验证模式”，但我们平时都是用SQL Server账号和密码连的，也就是“混合模式”。我得去确认一下。于是打开“SQL Server企业管理器”，找到我的数据库实例，右键点“属性”，然后选“安全性”那个标签。一看，果然，它不知道什么时候又被改回了“Windows身份验证”。真是气人！赶紧给它改成“SQL Server和Windows”这种混合模式。改完之后，它会提示要重启服务才能生效。没办法，又得去服务管理器那里，老规矩，停止再启动！

检查客户端情况和防火墙

服务器端该看的都看了，该调的都调了，如果还连不上，那我就得回过头来检查自己的电脑了，也就是客户端。我用的连接工具，不管是Query Analyzer还是我们自己写的应用程序，那连接字符串或者连接配置是不是写错了？服务器名、实例名、用户名、密码，一个字一个字地又核对了一遍。确认无误。

然后，我想到了客户端这边也有个“SQL Server客户端网络实用工具”。这玩意儿跟服务器端的工具差不多，但它是管我这台电脑怎么去连数据库的。我赶紧打开它，主要就是看它默认是用什么协议去连接的。一般是TCP/IP或者命名管道，得跟我服务器端开的一致。我把“默认协议”设成了“TCP/IP”。有时候为了方便，我们还会在这里给服务器设置个“别名”，比如把很长一串服务器名映射成一个短的名字，如果别名设置错了，或者别名对应的IP地址不对，那也连不上。我检查了一下，别名倒是没动过，应该不是这问题。

我就想到了最容易被忽略但又最致命的一环——防火墙。这几天我的电脑或者服务器上有没有谁动过防火墙设置？无论是我的本地Windows防火墙，还是服务器上的防火墙，它们都可能把SQL Server默认的1433端口（或者自定义的端口）给拦住了。我赶紧去我的电脑，打开“Windows防火墙”设置，看看有没有把SQL Server相关程序的出站规则给禁了，或者把1433端口的出站规则给限制了。也得去服务器上确认，有没有把1433端口的入站规则给堵死。我记得有一次就是防火墙没开那个1433端口，害我找了半天。这回我特意去防火墙的“入站规则”和“出站规则”里，把1433端口都给放行了，也就是“允许连接”。

等我把这些都检查了个遍，该重启的重启了，该调整的调整了。回到我的电脑，再次打开连接工具，小心翼翼地敲下连接按钮。这回屏幕上没有再跳出刺眼的“连接失败”了！而是弹出了熟悉的数据库列表！我当时心里的那块大石头“咣当”一声就落了地。真是折腾了小半天，原来是多方面原因交织在一起，又是服务没启动，又是协议被禁用，还可能是防火墙搞的鬼。这种老系统，真是哪哪儿都容易出问题，但只要有耐心，一步步地排查，总能找到症结所在。