Solution for General Network Error

Applies To: .NET 1.1

I think this is a common problem experienced by dotnet developers during different scenarios. There was a time when I faced this problem and stuggled to find a solution.Typically the application was to complete thousands of transactions and insert/update records into tables.At that time the app/service would just stop after a few hundred records throwing error the infamous "General Network Error". The problem with this is that you can't easily understand message or find the root cause of this problem.

A General Network Error can be due to a variety of causes (it just means the client lost its connection with a server), here are some:

1) Database corruption and/or a handled Exception (seen in a SQL Server checkdb report and/or a SQL Server errorlog respectively) causing a spid to be killed
2) A shutdown of the remote server while that stored procedure is executing (seen by inspecting the start time and end time between a pair of errorlogs).
3) A name resolution problem (WINS, LMHOSTS and/or DNS)
4) A SQL Server configuration problem (make sure http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q319942 are at defaults) in conjunction with an MDAC problem
5) A router problem, such as a "black hole router" (that fails to forward packets greater than a certain size, and of course
6) A Network problem related to the amount of data being sent - for example, for the purposes of a repro, try executing the contents of the stored procedure in Query Analyzer and (to test a different Database API), try isql.exe (which uses DB-Library)

In my case it happened because when you are doing large number of transactions consecutively and at that time due to some reasons a connection may become corrupt as mentioned above. So when this happens COM+ does not destroy it. It just simply puts the connection back in pool. When next operation gets this connection, it gives error. Some people suggest you to either make pooling=false in connection string always. This is not correct since then you don’t get the benefits of a connection pool. Also some suggest that increasing max pool size (typically order of thousands) in connection string solves this problem, may be this works but this will not be a correct approach to solve the problem.

To solve this, I changed a little bit of code in SQL Helper (cs version).(for ExecuteDataset, etc.,) like below and it worked like a charm and since then I have not seen this error. Effectively what this piece of code tried to do is when a connection becomes corrupt, it ignores the connection pool and gets a fresh connection that is not from the pool.

try{
cn.Open();
reset = true;
}
catch
{
cn = new SqlConnection(connectionString + ";Pooling=false");
cn.Open();
reset = true;
}
finally
{
if (reset == true)
{
DS = ExecuteDataset(cn, commandType, commandText, commandParameters);
}
cn.Close();
cn.Dispose();
}
return DS;

Seems to be this problem is solved in .NET 2.0.(http://blogs.msdn.com/angelsb/archive/2004/10/05/238153.aspx