在大容量 .NET 应用程序中，您可能会在尝试执行查询时看到此异常：
System.Data.SqlClient.SqlException：向服务器发送请求时发生传输级错误。
根据我的研究，这是“刚刚发生”的事情，无法采取任何措施来防止它。它不会由于错误的查询而发生，并且通常不能重复。当与数据库的 TCP 连接由于某种原因出现故障时，它可能每隔几天在繁忙的 OLTP 系统中出现一次。
我被迫通过解析异常消息来检测此错误，然后从头开始重试整个操作，包括使用新连接。这些都不漂亮。
有人有任何替代解决方案吗？
我在另一个主题上发布了另一个问题的答案，可能在这里有用。该答案涉及 SMB 连接，而不是 SQL。然而，它是相同的，因为它涉及一个低级别的传输错误。
我们发现，在负载较重的情况下，远程服务器很容易因为服务器繁忙而使 TCP 层的连接超时。部分原因是 TCP 在 Windows 上重新传输数据的默认值不适合我们的情况。
查看用于在 Windows 上调整 TCP/IP 的注册表设置。特别是您想查看TcpMaxDataRetransmissions和TcpMaxConnectRetransmissions。这些默认值分别为 5 和 2，尝试在客户端系统上稍微提高它们并复制负载情况。
不要发疯！TCP 会在每次连续重新传输时将超时时间加倍，因此如果您将这些超时时间增加太多，则不良连接的超时行为可能会呈指数增长。我记得在绝大多数情况下将TcpMaxDataRetransmissions 提高到 6 或 7 解决了我们的问题。
Michael Aspengren的这篇博文解释了错误消息“向服务器发送请求时发生了传输级错误”。
要回答您的原始问题：
在不解析错误消息的情况下检测此特定错误的一种更优雅的方法是检查Number.SqlException
（这实际上从集合SqlError中的第一个返回错误号Errors，但在您的情况下，传输错误应该是集合中唯一的错误号。）
我已经在自己的环境中多次看到这种情况发生。在这种情况下，客户端应用程序安装在许多机器上。其中一些机器恰好是笔记本电脑，人们让应用程序处于打开状态，断开连接，然后重新插入并尝试使用它。这将导致您提到的错误。
我的第一点是查看网络并确保服务器不在 DHCP 上并更新导致此错误的 IP 地址。如果不是这种情况，那么您必须开始在您的事件日志中搜索其他与网络相关的内容。
不幸的是，如上所述，这是一个网络错误。您可以做的主要事情就是使用 netmon 之类的工具监控连接，然后从那里开始工作。
祝你好运。
将企业服务与事务组件一起使用
我在我的数据库命令周围使用可靠性层（在存储库接口中抽象出来）。基本上，这只是拦截任何预期异常（DbException 和 InvalidOperationException，碰巧在连接问题上引发）、记录它、捕获统计信息并再次重试所有内容的代码。
有了这个可靠性层，服务就能够优雅地通过压力测试（不断的死锁、网络故障等）。生产远没有那么敌对。
PS：这里还有更多内容（以及使用拦截 DSL 定义可靠性的简单方法）
您还应该检查与数据库的硬件连接。
也许这个线程会有所帮助： http ://channel9.msdn.com/forums/TechOff/234271-Conenction-forcibly-closed-SQL-2005/
我有同样的问题。我问了我的网络极客朋友，都说这里的人都回答了：是电脑和数据库服务器的连接。就我而言，问题出在我的 Internet 服务提供商或路由器上。路由器更新后，问题就消失了。但是，您的计算机或服务器是否有任何其他互联网连接中断？我有...
我遇到了同样的问题，尽管它是对 SQL DB 的服务请求。
这是我的服务错误日志中的内容：
System.Data.SqlClient.SqlException：向服务器发送请求时发生传输级错误。（提供者：TCP 提供者，错误：0 - 现有连接被远程主机强行关闭。）
我有一个测试服务的 C# 测试套件。该服务和数据库都在外部服务器上，所以我认为这可能是问题所在。所以我在本地部署了服务和数据库无济于事。问题继续。测试套件甚至根本不是一个非常紧迫的性能测试，所以我不知道发生了什么。每次相同的测试都失败了，但是当我禁用该测试时，另一个测试会连续失败。
我尝试了互联网上建议的其他方法也不起作用：
我最后的手段是用古老的说法“再试一次”。因此，我嵌套了 try-catch 语句，以确保如果 TCP/IP 连接在较低的通信协议中丢失，它不仅会放弃，还会再次尝试。这现在对我有用，但它不是一个非常优雅的解决方案。
我今天早上在连接到 SQL 2008 R2 Express 时在 SSMS 中遇到了传输错误。
我正在尝试使用 \r\n 导入 CSV。我将行终止符编码为 0x0d0x0a。当我将其更改为 0x0a 时，错误停止了。我可以来回改变它并观察它发生/不发生。
BULK INSERT #t1 FROM 'C:\123\Import123.csv' WITH
( FIRSTROW = 1, FIELDTERMINATOR = ',', ROWTERMINATOR = '0x0d0x0a' )
我怀疑我没有正确编写行终止符，因为当我尝试传递两个字符时，SQL 一次解析一个字符。
无论如何，这个错误现在已经有 4 年了，但它可能会为下一个用户提供一些信息。
我只是想在这里发布一个对我们公司已安装的新软件有效的修复程序。自客户端日志文件的第 1 天起，我们收到以下错误：服务器无法处理请求。---> 从服务器接收结果时发生传输级错误。（提供者：TCP Provider，错误：0 - 信号量超时期限已到期。）---> 信号量超时期限已到期。
完全解决问题的是在我们的交换机上设置链路聚合 (LAG)。我们的戴尔 FX1 服务器背面有冗余光纤线。我们没有意识到他们插入的交换机需要在这两个端口上配置 LAG。在此处查看详细信息：https ://docs.meraki.com/display/MS/Switch+Ports#SwitchPorts-LinkAggregation