General Network Error: query->restart server->query again

[Guest]

connStr="Initial Catalog=EDEMO; Data Source=ELVIS;Integrated Security='sspi'"
conn=new SqlConnection(connStr);
conn.Open();
cmd=new SqlCommand(sql, conn);
cmd.ExecuteNonQuery();
conn.Close();
-------------------------------
restart the Sql Server (implemented by Process Object, abbreviated here)
-------------------------------
connStr="Initial Catalog=EDEMO; Data Source=ELVIS;Integrated Security='sspi'"
conn=new SqlConnection(connStr);
conn.Open();
cmd=new SqlCommand(sql, conn);
cmd.ExecuteNonQuery();
conn.Close();

when execute the second statment of "cmd.ExecuteNonQuery();" it will throw
an exception shown as follows:
General network error. Check your network
documentation.System.Data.SqlClient.SqlException: General network error.
Check your network documentation.
at System.Data.SqlClient.SqlCommand.ExecuteNonQuery()
at WinNTTest.Form1.button11_Click(Object sender, EventArgs e) in
e:\test\c#\winnttest\form1.cs:line 594

 

[Pablo Castro [MS]]

Unfortunately, this is a known issue with no official known work-arounds for
the current release.

What happens under the covers is that we use connection pooling to make
calls to Open() faster on average. In order to do that, when you call close
on a connection with pooling enabled (the default) we don't actually close
the connection, we return it to the pool instead.

So on the second call to Open we re-use the same connection. However, since
in between the server has been recycled, the connection is now broken; we
don't know about that until we try to use it, during Execute.

If this situation is completely unacceptable for your scenario, then you may
need to disable connection pooling (add "pooling=false" to the connection
string), but keep in mind that doing so will have a serious performance
impact to your app. The other option is to retry the call to
Open()/Execute*(), although that requires more coding, perhaps a common
wrapper around Open() and Execute*() that's used throughout the application.

We're working on this somewhat less of a problem in the next release.

--
Pablo Castro
Program Manager - ADO.NET Team
Microsoft Corp.

This posting is provided "AS IS" with no warranties, and confers no rights.