Need advice for tracking down a general network error exception

[Alan Pretre]

I have an application installed at a customer site that has been getting a
general network error for a couple of years. I was hoping that .NET 2.0
would clear it up, but unfortunately it didn't. The .NET 2.0 exception does
give a little more info than .NET 1.1 did, but not much.

Can anybody give any pointers about how to track this down? It occurs every
10 hrs around the clock, like clockwork.

I have included the stack trace, but omitted the trace from my code. The
application is attempting to fill a dataset from a SQL Server 2000 box. The
frequency at which it attempts this is customer defined, but I believe it is
doing it every minute. There are other applications at the customer site
using that server. It is not possible to disable them, as they run their
business. Haven't been able to duplicate this error inhouse.

Thanks.

-- Alan


System.Data.SqlClient.SqlException: A transport-level error has occurred
when sending the request to the server. (provider: Named Pipes Provider,
error: 0 - An unexpected network error occurred.)
Source: .Net SqlClient Data Provider
HResult: -2146232060 (0x80131904)
Errors Collection:
-------------------------------------
Class: 20
LineNumber: 0
Message: A transport-level error has occurred when sending the request to
the server. (provider: Named Pipes Provider, error: 0 - An unexpected
network error occurred.)
Number: 59
Procedure:
Server: xxxx2K3012
Source: .Net SqlClient Data Provider
State: 0
ErrorCode: -2146232060

System.Data.SqlClient.SqlException: A transport-level error has occurred
when sending the request to the server. (provider: Named Pipes Provider,
error: 0 - An unexpected network error occurred.)
at System.Data.SqlClient.SqlConnection.OnError(SqlException exception,
Boolean breakConnection)
at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException
exception, Boolean breakConnection)
at
System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject
stateObj)
at System.Data.SqlClient.TdsParserStateObject.ThrowExceptionAndWarning()
at System.Data.SqlClient.TdsParserStateObject.WriteSni()
at System.Data.SqlClient.TdsParserStateObject.WritePacket(Byte flushMode)
at System.Data.SqlClient.TdsParserStateObject.ExecuteFlush()
at System.Data.SqlClient.TdsParser.TdsExecuteRPC(_SqlRPC[] rpcArray,
Int32 timeout, Boolean inSchema, SqlNotificationRequest notificationRequest,
TdsParserStateObject stateObj)
at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior
cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async)
at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior
cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method,
DbAsyncResult result)
at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior
cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method)
at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior
behavior, String method)
at System.Data.SqlClient.SqlCommand.ExecuteDbDataReader(CommandBehavior
behavior)
at
System.Data.Common.DbCommand.System.Data.IDbCommand.ExecuteReader(CommandBehavior
behavior)
at System.Data.Common.DbDataAdapter.FillInternal(DataSet dataset,
DataTable[] datatables, Int32 startRecord, Int32 maxRecords, String
srcTable, IDbCommand command, CommandBehavior behavior)
at System.Data.Common.DbDataAdapter.Fill(DataSet dataSet, Int32
startRecord, Int32 maxRecords, String srcTable, IDbCommand command,
CommandBehavior behavior)
at System.Data.Common.DbDataAdapter.Fill(DataSet dataSet)

 

[Cor Ligthert [MVP]]

Alan,

If I see this, than I have forever to think about backupprocesses.

You are sure that such a kind of process is not interfering your application
and the standards it assumes.

As at least Bill Vaughn and I as well have seen is, that you can have this
kind this kind of problems even from a not good working light bulb or an
antenna from a car which is leaving the garage and hits the building.

Just a thought,

Cor

 

[Paul Clement]

¤ I have an application installed at a customer site that has been getting a
¤ general network error for a couple of years. I was hoping that .NET 2.0
¤ would clear it up, but unfortunately it didn't. The .NET 2.0 exception does
¤ give a little more info than .NET 1.1 did, but not much.
¤
¤ Can anybody give any pointers about how to track this down? It occurs every
¤ 10 hrs around the clock, like clockwork.
¤

The problem is network or database server related. It could be a temporary loss of network
connectivity or that the database server is temporarily unavailable and cannot handle the request.

Someone needs to monitor the network traffic and the database server in order to determine what
might be happening when this error occurs.


Paul
~~~~
Microsoft MVP (Visual Basic)

 

[Willy Denoyette [MVP]]

I could be wrong, but it looks like you keep the connection open all the
time, better would be to open the connection for each request. That would
give you more control to handle connection problems whenever they happen.
Another thing to watch for is wheter SQL is not scheduled for unattended
off-line back-ups. And a last question is why you are using a named pipe
transport protocol instead of TCP?

Willy.



|I have an application installed at a customer site that has been getting a
| general network error for a couple of years. I was hoping that .NET 2.0
| would clear it up, but unfortunately it didn't. The .NET 2.0 exception
does
| give a little more info than .NET 1.1 did, but not much.
|
| Can anybody give any pointers about how to track this down? It occurs
every
| 10 hrs around the clock, like clockwork.
|
| I have included the stack trace, but omitted the trace from my code. The
| application is attempting to fill a dataset from a SQL Server 2000 box.
The
| frequency at which it attempts this is customer defined, but I believe it
is
| doing it every minute. There are other applications at the customer site
| using that server. It is not possible to disable them, as they run their
| business. Haven't been able to duplicate this error inhouse.
|
| Thanks.
|
| -- Alan
|
|
| System.Data.SqlClient.SqlException: A transport-level error has occurred
| when sending the request to the server. (provider: Named Pipes Provider,
| error: 0 - An unexpected network error occurred.)
| Source: .Net SqlClient Data Provider
| HResult: -2146232060 (0x80131904)
| Errors Collection:
| -------------------------------------
| Class: 20
| LineNumber: 0
| Message: A transport-level error has occurred when sending the request
to
| the server. (provider: Named Pipes Provider, error: 0 - An unexpected
| network error occurred.)
| Number: 59
| Procedure:
| Server: xxxx2K3012
| Source: .Net SqlClient Data Provider
| State: 0
| ErrorCode: -2146232060
|
| System.Data.SqlClient.SqlException: A transport-level error has occurred
| when sending the request to the server. (provider: Named Pipes Provider,
| error: 0 - An unexpected network error occurred.)
| at System.Data.SqlClient.SqlConnection.OnError(SqlException exception,
| Boolean breakConnection)
| at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException
| exception, Boolean breakConnection)
| at
|
System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject
| stateObj)
| at System.Data.SqlClient.TdsParserStateObject.ThrowExceptionAndWarning()
| at System.Data.SqlClient.TdsParserStateObject.WriteSni()
| at System.Data.SqlClient.TdsParserStateObject.WritePacket(Byte
flushMode)
| at System.Data.SqlClient.TdsParserStateObject.ExecuteFlush()
| at System.Data.SqlClient.TdsParser.TdsExecuteRPC(_SqlRPC[] rpcArray,
| Int32 timeout, Boolean inSchema, SqlNotificationRequest
notificationRequest,
| TdsParserStateObject stateObj)
| at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior
| cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async)
| at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior
| cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method,
| DbAsyncResult result)
| at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior
| cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method)
| at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior
| behavior, String method)
| at System.Data.SqlClient.SqlCommand.ExecuteDbDataReader(CommandBehavior
| behavior)
| at
|
System.Data.Common.DbCommand.System.Data.IDbCommand.ExecuteReader(CommandBehavior
| behavior)
| at System.Data.Common.DbDataAdapter.FillInternal(DataSet dataset,
| DataTable[] datatables, Int32 startRecord, Int32 maxRecords, String
| srcTable, IDbCommand command, CommandBehavior behavior)
| at System.Data.Common.DbDataAdapter.Fill(DataSet dataSet, Int32
| startRecord, Int32 maxRecords, String srcTable, IDbCommand command,
| CommandBehavior behavior)
| at System.Data.Common.DbDataAdapter.Fill(DataSet dataSet)
|
|

 

[Alan Pretre]

I could be wrong, but it looks like you keep the connection open all the
time, better would be to open the connection for each request. That would
give you more control to handle connection problems whenever they happen.
Another thing to watch for is wheter SQL is not scheduled for unattended
off-line back-ups. And a last question is why you are using a named pipe
transport protocol instead of TCP?

Thanks, I am investigating the connection pooling situation. I was able to
track down this article, it may apply to me.

http://support.microsoft.com/default.aspx?scid=kb;en-us;328476

I don't knowingly have connection pooling disabled.

-- Alan

 

[Alan Pretre]

I could be wrong, but it looks like you keep the connection open all the
time, better would be to open the connection for each request. That would
give you more control to handle connection problems whenever they happen.

I have checked my connection string (not as obvious as it would seem, as it
is dynamically created), it looks like this:

user id=xxx ;password=xxx ;initial catalog=xxx ;data source=xxx;Connect
Timeout=15

I do not have Pooling=false in there.

I came across this article:

ADO.NET Connection Pooling FAQ
http://www.c-sharpcorner.com/Code/2004/May/PoolingNS.asp

In the section, "Tips and Tricks for better use of connection pooling", he
says this:

"Do not close all your connections in the pool, keep at least one
connection alive."

I wonder if this is my problem. Should I have an unused connection that is
always connected during the lifetime of the app, in addition to the ones
that I have now?

Another thing to watch for is wheter SQL is not scheduled for unattended
off-line back-ups.

This was a concern, but we have verified that they are not running backups
every 10 hrs.

And a last question is why you are using a named pipe transport protocol
instead of TCP?

Not sure about the answer to this one, I'll have to look into it. The
connection string I use is generated by a component from another group in my
company. (It is not static).


-- Alan

 

[Willy Denoyette [MVP]]

|
| | >I could be wrong, but it looks like you keep the connection open all the
| > time, better would be to open the connection for each request. That
would
| > give you more control to handle connection problems whenever they
happen.
| > Another thing to watch for is wheter SQL is not scheduled for unattended
| > off-line back-ups. And a last question is why you are using a named pipe
| > transport protocol instead of TCP?
|
| Thanks, I am investigating the connection pooling situation. I was able
to
| track down this article, it may apply to me.
|
| http://support.microsoft.com/default.aspx?scid=kb;en-us;328476
|
| I don't knowingly have connection pooling disabled.
|
| -- Alan
|
|

Connection pooling is on by default, the question remains however; do you
close the connection in the application yes or no? If you don't, you keep a
logical connection from the pool and this one keeps a physical connection
with SQL. In this case, the problem starts when the physical connection
breaks for one another reason, whenever you issue the fill request (on the
logical connection), an exception will be thrown on you. If however, you
close the logical connection after each 'transaction' and re-open the
logical connection at the start of the next one, the pool manager will pass
you an 'established' physical connection from the pool, not a broken one.
Of course this doesn't explain why a connection fails at regular intervals,
my experience is scheduled activities in the server running SQL,
synchronizing DNS servers and SQL in fail-over clusters.

About the KB article all I can say is that it applies to TCP protocol
connections, but you are using named pipes and my question was if you did
have any specific reason for that?
I also have no idea about your network infrastructure, how is the client
connected? through a switched network? are routers involved (take care here
with named pipes!).
What about the server, how many connections are there configured for SQL and
how many are there used at any time.

Willy.

 

[Alan Pretre]

Connection pooling is on by default, the question remains however; do you
close the connection in the application yes or no? If you don't, you keep
a
logical connection from the pool and this one keeps a physical connection
with SQL. In this case, the problem starts when the physical connection
breaks for one another reason, whenever you issue the fill request (on the
logical connection), an exception will be thrown on you. If however, you
close the logical connection after each 'transaction' and re-open the
logical connection at the start of the next one, the pool manager will
pass
you an 'established' physical connection from the pool, not a broken one.
Of course this doesn't explain why a connection fails at regular
intervals,
my experience is scheduled activities in the server running SQL,
synchronizing DNS servers and SQL in fail-over clusters.

This would be a typical fill. Note the Connection usage. Is this closing
the logical or physical connection?

public int Fill() {
int NumRows = 0;

using (System.Data.SqlClient.SqlConnection Connection = new
System.Data.SqlClient.SqlConnection(_Connection.ConnectionString)) {
Connection.Open();

using (cfgDevicesDataAdapter daDevices = new
cfgDevicesDataAdapter(Connection)) {
if (_Timeout >= 0) {
daDevices.CommandTimeout = _Timeout;
} else {
daDevices.ResetCommandTimeout();
}

// Specify all records, sort on DeviceName.
daDevices.All("DeviceName ASC");

// Read the records.
if (Connection.State == System.Data.ConnectionState.Open) {
bool OldEnforceConstraints = EnforceConstraints;
EnforceConstraints = false;
NumRows += daDevices.Fill(this);
EnforceConstraints = OldEnforceConstraints;
}
}
}

return NumRows;
}

I think I will need to add some retry logic around the Connection.Open().

About the KB article all I can say is that it applies to TCP protocol
connections, but you are using named pipes and my question was if you did
have any specific reason for that?

There is no good answer to this, I have already brought it up with the group
responsible for creating the connection string the possibility of either
defaulting or allowing the protocol to be specified. Right now, it is
simply unspecified, which I gather uses whatever the SQL Server is defaulted
to.

I also have no idea about your network infrastructure, how is the client
connected? through a switched network? are routers involved (take care
here
with named pipes!).
What about the server, how many connections are there configured for SQL
and
how many are there used at any time.

This stuff is a little hard to find out, as the sites are scattered around
the United States and other employees here do the installs. If I can get
this connection pooling stuff straightened out, and this TCP protocol
specified, maybe those are good avenues to pursue at this point.


Did you see my other post, where I asked the question about leaving another
"unused" connection open all the time?

-- Alan