将结果返回到客户端
　　服务器在准备将特定客户端请求的结果返回时，将使用最初接收请求时所用的网络堆栈。它通过服务器端 Net-Library 将结果发送到相应的网络协议，随后这些结果将通过网络以 TDS 格式返回到客户端。
　　在客户端上，客户端 Net-Library 将从服务器接收的 TDS 数据包从 IPC 层重新汇编，并将其继续转发到初始化该请求的 API 或对象库。
　　小结
　　尽管涉及了所有组件，但 SQL Server 客户端与服务器之间的往返过程却相当快 - 特别是在使用内存 Net-Library 时，亚秒响应时间非常普遍。构建和调整您自己的 SQL Server 客户端应用程序时，以下几个与数据相关的问题值得注意：
　　如果应用程序与 SQL Server 运行在同一台计算机上，则建议您使用共享内存 Net-Library（如果尚未使用它）。基于共享内存 Net-Library 的连接通常比其他类型的连接快很多。在注意上述内容的同时，还应：始终全面测试解决方案并将它与其他可行方案进行对比，这样才能判断它是否确实更好或更快。事实胜于雄辩。
　　由于客户端在第一次连接时将指定给特定的 UMS 计划程序，并只有在断开连接后，才会摆脱该计划程序的控制，因此确保在应用程序与服务器建立的连接上均衡分配工作负荷非常重要。工作负荷不均衡可导致不必要的 CPU 争用并降低资源使用率。
　　在服务器上配置的默认网络数据包大小以及客户端在连接时指定的网络数据包大小将直接影响它们在服务器上所需的内存量和分配内存的池。对服务器进行扩展性和速度配置时，应记住这一点。还应记住，默认情况下，ADO.NET 应用程序的网络数据包大小比 ADO 应用程序的更大。　
　　通常，在向服务器发送请求时，应首选 RPC 而非语言事件。为此，应在使用的 ADO 或 ADO.NET 对象中设置相应的属性。
　　执行动态 T-SQL 时，应在可能的情况下使用 sp_executesql 代替 EXEC()。唯一例外的情况是，当使用 EXEC() 的功能将查询片断连接而成的动态查询字符串的大小超过单个本地变量的存储大小时（这种情况非常少见）。
　　当遇到客户端问题，并且怀疑它可能和连接服务器时所用的对象库或 API 有关时，可以使用的一个故障排除技巧就是更改所用的客户端机制，这样可以将问题归结为特定的组件。例如，假设您升级 MDAC 并开始在 SQL Server 错误日志中看到 17805 错误，这表明客户端 ADO 应用程序发送的 TDS 数据包的格式不正确。您可能尝试让应用程序转为使用 ODBC 的 OLE DB 提供程序，如果您可以较为容易地做到这一点，应看看该问题是否与 SQLOLEDB 提供程序有一定的关系。相反，如果基于 ADO 的应用程序一直通过 ODBC 进行连接，则可以切换到 SQLOLEDB，看看这是否能解决问题，或至少帮助您缩小问题的范围。
　　同样，在对连接问题进行故障排除时，更改正在使用的 Net-Library 有时会有所帮助。如果使用 TCP/IP，命名管道也许值得一试。例如，如果 DHCP 服务器出现问题，并且没有有效的 IP 地址，则您将无法使用 TCP/IP 连接到 SQL Server。通过切换到命名管道，可以快速地将问题归结为 TCP/IP 特定的因素上。另一方面，如果在切换 Net Library 后仍存在同样的问题，则可以排除 Net-Library 方面的问题。问题的原因可能是服务器已关闭，或在您与服务器之间的某处网络基础设施无法正常工作。最后，还可以容易地更改应用程序使用的 Net-Library，而不必更改应用程序本身，这样就为您提供一个帮助缩小问题范围的工具。尽管从长远角度而言，使用某一特定 Net-Library 并不可行，但让客户端临时使用它可以帮助您缩小连接相关问题的范围。