[sql-server-2008] A transport-level error has occurred when receiving results from the server

I'm getting a SQL Server error:

A transport-level error has occurred when receiving results from the server. (provider: Shared Memory Provider, error: 0 - The handle is invalid.)

I'm running Sql Server 2008 SP1, Windows 2008 Standard 64 bit.

It's a .Net 4.0 web application. It happens when a request is made to the server. It's intermittent. Any idea how I can resolve it?

I had the same problem. I restarted Visual Studio and that fixed the problem

Look at the MSDN blog which details out this error:

Removing Connections

The connection pooler removes a connection from the pool after it has been idle for a long time, or if the pooler detects that the connection with the server has been severed.

Note that a severed connection can be detected only after attempting to communicate with the server. If a connection is found that is no longer connected to the server, it is marked as invalid.

Invalid connections are removed from the connection pool only when they are closed or reclaimed.

If a connection exists to a server that has disappeared, this connection can be drawn from the pool even if the connection pooler has not detected the severed connection and marked it as invalid.

This is the case because the overhead of checking that the connection is still valid would eliminate the benefits of having a pooler by causing another round trip to the server to occur.

When this occurs, the first attempt to use the connection will detect that the connection has been severed, and an exception is thrown.

Basically what you are seeing is that exception in the last sentence.

A connection is taken from the connection pool, the application does not know that the physical connection is gone, an attempt to use it is done under the assumption that the physical connection is still there.

And you get your exception.

There are a few common reasons for this.

1. The server has been restarted, this will close the existing connections.

In this case, have a look at the SQL Server log, usually found at: C:\Program Files\Microsoft SQL Server\\MSSQL\LOG

If the timestamp for startup is very recent, then we can suspect that this is what caused the error. Try to correlate this timestamp with the time of exception.

2009-04-16 11:32:15.62 Server Logging SQL Server messages in file ‘C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\LOG\ERRORLOG’.

2. Someone or something has killed the SPID that is being used.

Again, take a look in the SQL Server log. If you find a kill, try to correlate this timestamp with the time of exception.

2009-04-16 11:34:09.57 spidXX Process ID XX was killed by hostname xxxxx, host process ID XXXX.

3. There is a failover (in a mirror setup for example) again, take a look in the SQL Server log.

If there is a failover, try to correlate this timestamp with the time of exception.

2009-04-16 11:35:12.93 spidXX The mirrored database “” is changing roles from “PRINCIPAL” to “MIRROR” due to Failover.

I faced the same issue recently, but i was not able to get answer in google. So thought of sharing it here, so that it can help someone in future.

Error:

While executing query the query will provide few output then it will throw below error.

"Transport level error has occurred when receiving output from server(TCP:provider,error:0- specified network name is no longer available"

Solution:

1. Check the provider of that linked server
2. In that provider properties ,Enable "Allow inprocess" option for that particular provider to fix the issue.

You get this message when your script make SQL Service stopped for some reasons. so if you start SQL Service again perhaps your problem will be resolved.

The database connection is closed by the database server. The connection remains valid in the connection pool of your app; as a result, when you pickup the shared connection string and try to execute it's not able to reach the database. If you are developing Visual Studio, simply close the temporary web server on your task bar.

If it happens in production, resetting your application pool for your web site should recycle the connection pool.

It happened to me when I was trying to restore a SQL database and checked following Check Box in Options tab,

As it's a stand alone database server just closing down SSMS and reopening it solved the issue for me.

For those not using IIS, I had this issue when debugging with Visual Studio 2010. I ended all of the debugger processes: WebDev.WebServer40.EXE which solved the issue.

Was getting this, always after about 5 minutes of operation. Investigated and found that a warning from e1iexpress always occurred before the failure. This apparently is an error having to do with certain TCP/IP adapters. But changing from WiFi to hardwired didn't affect it.

So tried Plan B and restarted Visual Studio. Then it worked fine.

On closer study I noticed that, when working correctly, the message The Thread '<No Name>' has exited with code 0 occurred at almost exactly the time the run crashed in previous attempts. Some Googling reveals that that message comes up when (among other things) the server is trimming the thread pool.

Presumably there was a bogus thread in the thread pool and every time the server attempted to "trim" it it took the app down.

Transport level errors are often linked to the connection to sql server being broken ... usually network.

Timeout Expired is usually thrown when a sql query takes too long to run.

So few options can be :

1. Check for the connection in VPN (if used) or any other tool
2. Restart IIS
3. Restart machine
4. Optimize sql queries.

This occurs when the database is dropped and re-created some shared resources is still considering the database still exists, so when you re-run execute query to create tables in the database after it was re-created the error will not show again and Command(s) completed successfully. message will show instead of the error message 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.).

Simply ignore this error when you are dropping and recreating databases and re-execute your DDL queries with no worries.

One of the reason I found for this error is 'Packet Size=xxxxx' in connection string. if the value of xxxx is too large, we will see this error. Either remove this value and let SQL server handle it or keep it low, depending on the network capabilities.

I got the same error in Visual Studion 2012 development environment, stopped the IIS Express and rerun the application, it started working.

I know this may not help everyone (who knows, maybe yes), but I had the same problem and after some time, we realized that the cause was something out of the code itself.

The computer trying to reach the server, was in another network, the connection could be established but then dropped.

The way we used to fix it, was to add a static route to the computer, allowing direct access to the server without passing thru the firewall.

route add –p YourServerNetwork mask NetworkMask Router 

Sample:

route add –p 172.16.12.0 mask 255.255.255.0 192.168.11.2 

I hope it helps someone, it's better to have this, at least as a clue, so if you face it, you know how to solve it.

We encountered this error recently between our business server and our database server. The solution for us was to disable "IP Offloading" on the network interfaces. Then the error went away.

If you are connected to your database via Microsoft SQL Server Management, close all your connections and retry. Had this error when connected to another Azure Database, and worked for me when closed it. Still don't know why ..

In my case the "SQL Server" Server service stopped. When I restarted the service that enabled me to run the query and eliminate the error.

Its also a good idea to examine your query to find out why the query made this service stop

All you need is to Stop the ASP.NET Development Server and run the project again

For me the solution was totally different.

In my case I had an objectsource which required a datetimestamp parameter. Even though that ODS parameter ConvertEmptyStringToNull was true 1/1/0001 was being passed to SelectMethod. That in turn caused a sql datetime overflow exception when that datetime was passed to the sql server.

Added an additional check for datetime.year != 0001 and that solved it for me.

Weird that it would throw a transport level error and not a datetime overflow error. Anyways..

For me the answer is to upgrade the OS from 2008R2 to 2012R2, the solution of iisreset or restart apppool didn't work for me. I also tried to turn of TCP Chimney Offload setting, but I didn't restart the server because it is a production server, which didn't work either.

I had the same issue. I solved it, truncating the SQL Server LOG. Check doing that, and then tell us, if this solution helped you.

Try the following command on the command prompt:

netsh interface tcp set global autotuning=disabled

This turns off the auto scaling abilities of the network stack