Dev Notes

The .CommandTimeOut property has some bugs, not just when used via the DAAB. I have found that setting it to 0 "unlimited" works on some machines and simply doesn't on others.

Worse, it seems that the macine actually running the ADO code isn't the problem, but the SQL Server, somehow :) Here's an example:

Two web servers, running the same code, using web.config for the ConnectionString. Everything identical except for the ConnectionStrings. Point one app at SQLServerA and one at SQLServerB, one has this problem, one does not.

Very strange. My fix? Set CommandTimeOut to 90 :(

What's even stranger: If you dim but don't even use an ADO.OLD Command object, and set IT'S timeout to 0, even the ADO.NET one works! Bleh!

Sudha,

Ofcourse I agree to this issue and partially to your resolution.

These are my 2 cents :)

1. CommandTimeOut is unfair as Travis has pointed out hence we cannot rely on setting the timeout to an specific or arbitary value. What otherwise I had done in our app is to provide a helper method which will set a static var in sqlHelper (yup i defined that) which is used a multiplier for the default timeout for sqlCommand object.
In case of this specific error I would rather poll the same db call again for n instances and if after the last(nth) time it keeps failing report the error back to the caller (user).

This scenario is usefull in my app as I need to keep polling till I can and atlast give up for web apps this might not be the case but the timeout multiplier which I use has done its job more than a few times.

2. I have also seen an instance when you MIGHT get this error is in case you do not explicitly set your sproc parameters from ado.net and simply call the sqlhelper's methods.
What internally happens is sqlClient smartly assigns the parameters which you have set in ado.net to the relevant datatypes in the sproc parameters and sends them without a hitch. But this badly fails when you are sending heavy data like nText paramters where in the paramter might result in a wrong conversion from sql client and result in sql server spitting out a severe error. In which case also you might see the same error.

Moral of the story:
1. Do not perform ado.net calls without specifying the sqlParameter type & direction.
2. The DAAB come with source code hence tweak it to match your requirements as best as suited.

I read from another site. I tried the method provided there. I added to the connection string "POOLING=FALSE", and it seems that my problem is solved. Before this, I tried to set commandTimeout = 90, or using an oleDb commaned, and set its time out to be 90, neither completely solved my problem. But it seems that the "POOLING=FALSE" worked for my case. I am using sql server 2000. I am not sure the version of my ADO.net.

I don't know if I would give up connection pooling ( pooling=false ); that's a big performance boost. I have this problem as well but more inclined to set the timeout or do as tuecer eluded to finite polling.

i'll continue to search for a method. perhaps, it's inevitable that we have random solutions for a common problem -- now that's what i call resolution. ;)

Teucer, you're a genius!

I had the same problem and explicitly setting the SQL Parameters datatype and direction for my stored proc worked like a charm.

I am sending about 8000 text characters to the stored proc which is looking for a varchar for that particular parameter.

Good job figuring that one out!

I had a very similar problem. StringBuilding large insert statements ~(2mb) on the client and calling SqlHelper.ExecuteNonQuery() using DAAB would give the "General Network Error".
However, using ADO.NET directly (ie. Creating a SqlCommand and calling ExecuteNonQuery() ... ) would still break, but I would get:

Message: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
Source: .Net SqlClient Data Provider
Class: 10
LineNumber: 0
Number: -2
Procedure: ConnectionRead (recv()).
Server:
State: 0

which is a lot more helpful!

So following that, Changing the code back to use DAAB and modifying the CommandTimeOut on the connection string from 0 to 60 works fine.

We had a support call to Microsoft on the issue. We had a certain situation that was repeatable for the General Network Error. We were getting it on the ConnectionRead (recv()) procedure.

Looking at the Packet Trace, the failure case generated packets with A..R bits set.
TCP: Flags = 0x14 : .A.R..
As described in KB Article 328476:
http://support.microsoft.com/?kbid=328476

But after a support call to Microsoft this KB article 823679 was the solution, Fix: Multiple Fixes for SQL Server .NET Data Provider.
http://support.microsoft.com/default.aspx?scid=kb;en-us;823679

"When the SQLCommand.CommandTimeout is set to zero, you expect an infinite timeout. However, versions 1.1 and 1.0 of the SqlClient provider incorrectly timeout when a response from SQL Server is broken into two packets. Immediately upon receipt of the second packet, versions 1.1 and 1.0 of the provider incorrectly timeout. The fix that is included in this article fixes this issue so that the command will have an infinite timeout."

The support person recommended avoiding use of .CommandTimeout = 0 if possible. The thought was that in a .NET 1.1 service pack release, this fix might be available.

Thanks a lot! Setting CommandTimeout to some high number resolved this annoying "General Network Error" problem here!!

Lana.

WebserverTalk

I suddenly started getting this problem after updating my machines to SQL2000 SP4

My app is a vb6 app using the OLEDB.1 driver

I have noticed that if i try to connect from a machine that has sp4 installed everything works fine but if the clent does not have SQLServer 2000 SP4 installed on itself (why would i want to do that) I get the error

Hello all,

i will just state my experience and i dont know exactly what happened. i had the same general network error on a local lan, with sql server 2000 at random cases. one command may work 10 times without a porblem then fails and then works fine again then fail again. no rules.

i solved the problem finaly by using a better network card on the client machines.

i am not sure how is this related but after i changed the network cards, i have never seen this problem again.

regards

Hi All,

When i am trying to connect SQL server by using SQL connection from C#.NET application i am receiving the error

[DBNETLIB][ConnectionRead (WrapperRead()).]General network error. Check your network documentation

But i am able login to sql server directly with same login credentials which i am using in code.

My code used to work but suddenly i am getting this error.

can you please help in resolving this issue.

You can also mail me your suggestions on mail id (nareddykrishna@gmail.com)

Thanks for your help

thanks my problem is nulled :S

I have the same problem "General network error.  Check your network documentation", when I try to connect to the SQL server 2000 from the Pocket PC with this code:

ConnectionString = @"Data Source=MyServer,1433; Initial Catalog=MyDataBase; User ID=MyuserId; Password=MyPass; Integrated Security=SSPI;";

I had the same problem when I upgraded my code from VS 2003 to VS 2005.

The steps below fixed my problem:

The old application used OLEDB. I used  ASPCompat="true" in the page directive of the updated version VS 2005.

I then I added impersonation in my web.config as follows:

<identity impersonate="true" userName="" password="" />