一段时间以来，我们的旗舰应用程序一直出现神秘错误。错误消息是通用的
[DBNETLIB][ConnectionWrite (send()).]一般网络错误。检查您的网络文档。
通过让应用程序在晚上打开并在早上恢复工作，可以可靠地重现这一点。由于它是后端服务器应用程序，因此这是一种正常情况。
有趣的是 - 我们已经从 SQL Server 7 迁移到 2000 到 2008 并且所有这些问题都存在。但似乎重要的是我们运行应用程序的操作系统。在 WinXP 上它工作正常，在 Vista/7 上它失败了。所以问题出在客户端。
谷歌对错误消息的结果涵盖了非常广泛的不同原因（因为这是一个非常普遍的错误），并且没有发现与我们相似的场景。
所以也许这里有人会知道我们的问题是什么？
您应该能够通过以下方式按需重现此错误情况：
1. 打开数据库连接（在您的客户端应用程序中）
2. 拔下网络电缆
3. 重新插入网络电缆（等待网络连接恢复）
4. 使用之前打开的查询数据库的连接
据我所知，客户端 ADO 代码无法始终如一地确定底层网络连接是否实际有效。检查数据库连接是否打开（在客户端代码中）返回 true。但是，对该连接执行任何操作都会导致General network error.
连接池似乎能够确定连接何时“坏”，因此它永远不会向应用程序返回坏连接。它只是打开一个新连接。
因此，如果应用程序长时间（使用或未使用）数据库连接保持活动状态，则底层 TCP/IP 连接可能会中断。
底线是数据库连接应该在不使用时关闭并返回到连接池。
此外，根据连接到数据库的客户端数量，不使用连接池可能会导致另一个问题。您可能会达到服务器端打开的最大套接字数。这是来自记忆。一旦在客户端关闭连接，服务器上的连接就会进入 TIME_WAIT 状态。默认情况下，服务器套接字大约需要 4 分钟才能关闭，因此在此期间它对其他客户端不可用。底线是服务器上可用的套接字数量有限。保持打开太多连接会产生问题。
我参与的一个项目很容易达到这个套接字限制，大约有 120 个用户。添加了一个新的“功能”，这绝对是服务器的重中之重，在使用该应用程序几个小时后，每个人的事情都会突然变慢。SQL Server 没有为新的连接请求及时关闭足够的套接字。虽然总共有 65K 个套接字，但只有前 5000 个可用于 ADO（这是默认的注册表设置，因此可以更改）。
处于 TIME_WAIT 状态的套接字数量会慢慢增加，直到操作系统不再分配。因此客户端必须等到服务器端套接字关闭，然后才能创建新连接。
您是否尝试过禁用SNP/TCP 烟囱？
有类似的错误。WSACleanup对我来说，这是由对和的不匹配调用间接引起的WSAStartup。
该程序调用WSACleanup的次数超过WSAStartup. 这会导致引用计数器（在套接字库中的某个位置）过早地达到零。
我认为从那一刻起，该进程拥有的所有套接字都被破坏了。
这也会杀死 SQL 客户端，因为它也使用套接字与 SQL 服务器“对话”。