从服务器接收结果时发生传输级错误
我得到一个SQL Server错误：
从服务器接收结果时发生传输级错误。 （提供程序：共享内存提供程序，错误：0 – 句柄无效。）
我正在运行Sql Server 2008 SP1，Windows 2008 Standard 64位。
这是一个.Net 4.0 Web应用程序。 这发生在向服务器发出请求时。 这是间歇性的。 任何想法如何解决它？
数据库连接被数据库服务器closures。 该连接在您的应用的连接池中保持有效; 因此，当您拾取共享连接string，并尝试执行它无法访问数据库。 如果您正在开发Visual Studio，只需closures任务栏上的临时Web服务器即可。
如果它在生产中发生，重置您的Web站点的应用程序池应该回收连接池。
在命令提示符处尝试以下命令：
netsh interface tcp set global autotuning=disabled
这将closuresnetworking堆栈的自动扩展function
对于那些不使用IIS，我用Visual Studio 2010进行debugging时遇到了这个问题。我结束了所有的debugging器进程：WebDev.WebServer40.EXE，它解决了这个问题。
我有同样的问题。 我重新启动Visual Studio，并解决了这个问题
所有你需要的是停止ASP.NET开发服务器并再次运行项目
总是在大约5分钟的操作之后得到这个。 调查发现，在发生故障之前，总是发生一个警告。 这显然是与某些TCP / IP适配器有关的错误。 但是从WiFi转换到硬连线并没有影响到它。
所以尝试了B计划并重新启动了Visual Studio。 然后它工作正常。
在仔细研究之后，我注意到，在正常工作时， The Thread '<No Name>' has exited with code 0的消息几乎是在之前尝试运行崩溃时发生的。 一些谷歌search显示，当（除其他之外）服务器正在修剪线程池时出现该消息。
据推测，线程池中有一个虚假的线程，每次服务器试图“修剪”它就把应用程序closures了。
如果通过Microsoft SQL Server Management连接到数据库，请closures所有连接并重试。 连接到另一个Azure数据库时出现此错误，并在closures时为我工作。 仍然不知道为什么..
当您的脚本由于某些原因使SQL Service停止时，您会收到此消息。 所以如果你再次启动SQL服务，也许你的问题将得到解决。
我知道这可能不会帮助每个人（谁知道，也许是的），但我有同样的问题，过了一段时间，我们意识到原因是代码本身。
计算机试图到达服务器，在另一个networking中，连接可以build立，但随后被丢弃。
我们用来解决这个问题的方法是为计算机添加一条静态路由，允许直接访问服务器而不通过防火墙。
route add –p YourServerNetwork mask NetworkMask Router
样品：
route add –p 172.16.12.0 mask 255.255.255.0 192.168.11.2
我希望它能帮助别人，至less可以把它作为一个线索，所以如果你面对这个问题，你就知道如何解决这个问题。
传输级别的错误通常与连接到sql server的连接断开…通常是networking连接。
超时过期通常会在sql查询运行时间太长时引发。
所以几个选项可以是：
- 检查VPN（如果使用）或任何其他工具的连接
- 重新启动IIS
- 重新启动机器
- 优化SQL查询。
我在Visual Studion 2012开发环境中遇到同样的错误，停止IIS Express并重新运行应用程序，它开始工作。
看看这个错误的详细MSDN博客 ：
删除连接
连接池在闲置很长一段时间后会从池中删除连接，或者如果池中检测到与服务器的连接已被切断。
请注意，只有在尝试与服务器通信后才能检测到已断开的连接。 如果发现连接不再连接到服务器，则将其标记为无效。
无效的连接仅在closures或回收时从连接池中删除。
如果连接存在一个已经消失的服务器，即使连接池没有检测到断开的连接并将其标记为无效，也可以从池中获取此连接。
这种情况是因为检查连接是否仍然有效的开销会通过导致服务器再次往返发生，从而消除了使用池的好处。
发生这种情况时，首次尝试使用连接将检测到连接已被切断，并引发exception。
基本上你看到的是最后一句中的例外。
从连接池中获取连接，应用程序不知道物理连接已经消失，尝试使用它是在假定物理连接仍然存在的情况下完成的。
你会得到你的例外。
这有几个常见的原因。
- 服务器已经重新启动，这将closures现有的连接。
在这种情况下，请查看SQL Server日志，通常位于：C：\ Program Files \ Microsoft SQL Server \\ MSSQL \ LOG
如果启动的时间戳是最近的，那么我们可以怀疑这是什么导致的错误。 尝试将此时间戳与exception时间关联起来。
2009-04-16 11：32：15.62服务器logging文件“C：\ Program Files \ Microsoft SQL Server \ MSSQL.1 \ MSSQL \ LOG \ ERRORLOG”中的SQL Server消息。
- 有人或某事已经杀死了正在使用的SPID。
再看一下SQL Server日志。 如果发现杀手，请尝试将此时间戳与exception时间关联起来。
2009-04-16 11：34：09.57 spidXX进程号XX被主机名xxxxx杀死，主机进程号XXXX。
- 还有一个故障转移（例如在镜像设置中），请查看SQL Server日志。
如果存在故障转移，请尝试将此时间戳与exception时间关联起来。
2009-04-16 11：35：12.93 spidXX由于故障切换，镜像数据库“”正将angular色从“PRINCIPAL”更改为“MIRROR”。
我遇到过同样的问题。 我解决了它，截断SQL Server日志。 检查一下，然后告诉我们，如果这个解决scheme对你有帮助。
对我来说，答案是将操作系统从2008R2升级到2012R2，iisreset或重新启动应用程序的解决scheme不适合我。 我也尝试过TCP烟囱卸载设置，但是我没有重启服务器，因为它是一个生产服务器，也没有工作。
对我来说，解决scheme是完全不同的。
在我的情况下，我有一个对象，它需要一个datetimestamp参数。 即使该ODS参数ConvertEmptyStringToNull为真1/1/0001被传递给SelectMethod。 这反过来导致了一个SQLdate时间溢出exception时，该date时间传递给SQL服务器。
为datetime.year！= 0001增加了一个检查，为我解决了这个问题。
奇怪的是，它会抛出一个传输级错误，而不是一个date时间溢出错误。 无论如何..
我们最近在业务服务器和数据库服务器之间遇到了这个错误。 我们的解决scheme是禁用networking接口上的“IP卸载”。 然后错误消失了。
我发现这个错误的原因之一是连接string中的“ Packet Size = xxxxx ”。 如果xxxx的值太大，我们会看到这个错误。 要么删除这个值，让SQL服务器处理它或保持低，这取决于networking的能力。
它发生在我正在尝试恢复SQL数据库，并选中Options卡中的checkbox，
因为它是一个独立的数据库服务器，closuresSSMS并重新打开它解决了我的问题。
在我的情况下，“SQL Server”服务器服务停止。 当我重新启动服务，使我能够运行查询，并消除错误。
查看查询以查明为什么查询使此服务停止也是一个好主意
这发生在数据库被删除和重新创build时，一些共享资源仍在考虑数据库仍然存在，所以当你重新运行执行查询来重新创build数据库中创build表后，错误将不会再显示和Command(s) completed successfully. 消息将显示，而不是错误消息Msg 233, Level 20, State 0, Line 0 A transport-level error has occurred when sending the request to the server. (provider: Shared Memory Provider, error: 0 - No process is on the other end of the pipe.) Msg 233, Level 20, State 0, Line 0 A transport-level error has occurred when sending the request to the server. (provider: Shared Memory Provider, error: 0 - No process is on the other end of the pipe.) 。
当您丢弃并重新创build数据库并重新执行DDL查询时，只需忽略此错误即可。
我最近面临同样的问题，但我无法在google中得到答案。 所以想到在这里分享它，以便将来可以帮助别人。
错误：
执行查询时，查询将提供less量的输出，然后将抛出错误。
“从服务器接收输出时发生传输级别错误（TCP：provider，错误：0 – 指定的networking名称不再可用”
解：
- 检查该链接服务器的提供者
- 在该提供程序属性中，为该特定提供程序启用“允许进程内”选项来解决该问题。
