ADO.NET & MS SQL 2000 - General Network Error

R

Rob R. Ainscough

I have a .NET Windows application that works perfectly (no errors) when it
communicates with my SQL Server locally (LAN). The exact same application
when executed on another PC outside our LAN (via Broadband connection) will
start to generate the following error:

Description:
11: System.Data.SqlClient.SqlException: General network error. Check your
network documentation.
at System.Data.SqlClient.SqlDataReader.InternalClose(Boolean closeReader)
at System.Data.SqlClient.SqlDataReader.Close()
at System.Data.SqlClient.SqlConnection.CloseReader()
at System.Data.SqlClient.SqlConnection.Close()

The problem appears to be random yet consistant, meaning it will happen
consistantly but never at the same point. And then sometimes it will clear
itself up and then continue processing and sometimes not.

The ONLY variable in the equation is LAN vs. Broadband connection. LAN
connection to the SQL Server never generates any errors. Broadband
connection to the SQL Server will generate the above errors at random
intervals.

I've tried the following "guess work" solutions I found via Google search:

Pooling=False
Max Pool Size = 300
Connect Timeout=90
Turn off Indexing Services

None of these resolve the problem. I've also checked and double checked my
code (even as far as putting a trace on the code) to make sure any data
readers are closed -- the only common thing I've noted is that a data reader
is always somehow involved -- it is as if the data reader (ADO.NET) requires
a high speed connection (aka LAN) to function reliably. If the data reader
is placed on a low speed connection it becomes unreliable/unstable.

http://weblogs.asp.net/ssadasivuni/archive/2003/12/06/41705.aspx

At least I know I'm not alone in this problem.

Rob.
 
F

Frans Bouma [C# MVP]

Rob said:
I have a .NET Windows application that works perfectly (no errors)
when it communicates with my SQL Server locally (LAN). The exact
same application when executed on another PC outside our LAN (via
Broadband connection) will start to generate the following error:

Description:
11: System.Data.SqlClient.SqlException: General network error. Check
your network documentation.
at System.Data.SqlClient.SqlDataReader.InternalClose(Boolean
closeReader) at System.Data.SqlClient.SqlDataReader.Close()
at System.Data.SqlClient.SqlConnection.CloseReader()
at System.Data.SqlClient.SqlConnection.Close()

The problem appears to be random yet consistant, meaning it will
happen consistantly but never at the same point. And then sometimes
it will clear itself up and then continue processing and sometimes
not.

The ONLY variable in the equation is LAN vs. Broadband connection.
LAN connection to the SQL Server never generates any errors.
Broadband connection to the SQL Server will generate the above errors
at random intervals.

I've tried the following "guess work" solutions I found via Google
search:

Pooling=False
Max Pool Size = 300
Connect Timeout=90
Turn off Indexing Services

None of these resolve the problem. I've also checked and double
checked my code (even as far as putting a trace on the code) to make
sure any data readers are closed -- the only common thing I've noted
is that a data reader is always somehow involved -- it is as if the
data reader (ADO.NET) requires a high speed connection (aka LAN) to
function reliably. If the data reader is placed on a low speed
connection it becomes unreliable/unstable.

Could it be the connection is dropped for some reason or timeouts?

FB

--
 
G

Guest

I would look at the Broadband lag and see if it is enough to go past your
command timeout limit.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************
 
R

Rob R. Ainscough

That is a good link full with interesting information, unfortunately I'm not
having any luck;

I've set CommandTimeOut - 120 and that didn't help

During attempts to close a connection I get this error:

Description:
System.InvalidOperationException: Internal connection fatal error.
at System.Data.SqlClient.SqlDataReader.InternalClose(Boolean closeReader)
at System.Data.SqlClient.SqlDataReader.Close()
at System.Data.SqlClient.SqlConnection.CloseReader()
at System.Data.SqlClient.SqlConnection.Close()

Rob
 
S

scorpion53061

OK sounds like your server has a data packet drop problem.

Start with the obvious. Check the router and the cables going to the
router or hub. Make sure your DNS is pointed correctly.

If that does not solve the problem do a ping on your server and the port
involved so that it never ends until you tell it to. Watch and see how
many packets are dropped. Even one in a thousand is too much.

I have noted that certain unnamed cable carriers have the problem that
they packets won't stay up. Why I am not sure. But it plays havoc with
any connection to a database. Especially during transactions.

(As a side note, you can help with these issues by never leaving your
connection open no longer than absolutely necessary. Always make sure
you close it as soon as you can.)

If it turns out to be them (do a google on your carrier and "dropped
packets") your pretty much SOL unless your complaints cause them to take
action.

Kelly
 
S

scorpion53061

OK sounds like your server has a data packet drop problem.

Start with the obvious. Check the router and the cables going to the
router or hub. Make sure your DNS is pointed correctly.

If that does not solve the problem do a ping on your server and the port
involved so that it never ends until you tell it to. Watch and see how
many packets are dropped. Even one in a thousand is too much.

I have noted that certain unnamed cable carriers have the problem that
they packets won't stay up. Why I am not sure. But it plays havoc with
any connection to a database. Especially during transactions.

(As a side note, you can help with these issues by never leaving your
connection open no longer than absolutely necessary. Always make sure
you close it as soon as you can.)

If it turns out to be them (do a google on your carrier and "dropped
packets") your pretty much SOL unless your complaints cause them to take
action.

Kelly
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top