• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1755
  • Last Modified:

ConnectionRead (WrapperRead()) Error

O/S Win2k Advanced Server
Running SQL Server sp3

Using
MDAC 2,80,1022,3
ADO 2.8
VB 6

For a while now our SQL server has been returning this error:
[DBNETLIB][ConnectionRead (WrapperRead()).]General network error. Check your network documentation

It seems that many people have run into this problem but not much in solutions has really been posted (well, at least not one that works for me)

It gets very troublesome since it seems that the database gets locked when this error is generated.  To provide a temporary remedy I have to clear all connections to the database, sometimes more than once.  I have been searching the web for a while and have been trying to find a remedy for this and trying any solution I have found that may provide a solution to this problem.  Turnging connection pooling off (in reference to kb article http://support.microsoft.com/default.aspx?scid=kb;en-us;Q229564).

This problem isn't happening on all databases either, which makes this even more troublesome.

Everything at the database level seems to be checking out (I've run DBCC checks with no errors being generated in reference to http://www.experts-exchange.com/Databases/Microsoft_SQL_Server/Q_21076842.html).  I've tried running performance traces to see if there is a TCP reset that is happening but haven't seen one yet.  It seems that a TCP reset is probably causing the error but I can't seem to find it.  In looking at KB I found the following article: http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/Q154/6/28.asp&NoWebContent=1 and applied this fix hoping that this was the problem causing TCP resets.  The problem was not fixed by this.  The named pipes and TCP settings in the client network utility are fine and the web server recognizes by IP and Name.

Any help would be greatly appreciated.
0
poliguin
Asked:
poliguin
  • 4
  • 4
  • 3
2 Solutions
 
ShogunWadeCommented:
Might be the completely wrong in your case,  but I had a similar error some time ago on a heavily stressed server.   It turned out that the raid controller card was intermittently flaking out and coming back.   Replaced the controller and its been ok since.
0
 
poliguinAuthor Commented:
That's worth a shot.  I don't get to control such decisions, etc but I'll see if that works.
0
 
ShogunWadeCommented:
check in your system event log and application log for any disk errors.  or if you have something like a PERC controller (which we have) there were a series on events in the raid diagnostic software.

0
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

 
arbertCommented:
Agree with ShogunWade....I've found that when most of these errors have happened it's because of overly HIGH IO on the server....

I really hate this error 'cause it really isn't indicative of what the problem might actually be!
0
 
ShogunWadeCommented:
"I really hate this error 'cause it really isn't indicative of what the problem might actually be!"

Me too,  unfortunately I didnt discover what it was in my case untill the controller died completely ;(
0
 
arbertCommented:
Ouch!  

I don't want to hijack the question, but shogun, why don't you drop me an email sometime--my addy is in my profile....

Brett
0
 
ShogunWadeCommented:
will do
0
 
poliguinAuthor Commented:
highjack away.  I'm going to have someone look into the Raid controller and see if that's the problem.  If it isn't then I'll try and get the thread back, ha.
0
 
poliguinAuthor Commented:
after doing more research and it seems to be pointing to the client connection reseting the connection.  i've come to this conclusion after finally finding a query that i've found to cause the problem from several different locations and have found that when i do it remotely that i end up getting this error back.

it also helped when i finally got enterprise manager to return the error [microsoft][odbc SQL Server Driver]Communication Link Failure.  it's kind of funny that i should be getting a connection timeout error since the offending query i've been running exceeds the connection timeout but instead decides it wants to return this error instead and lock the database up (the connections are getting properly closed within the error handling).

finding where this tcp reset is the part that i have no idea about.  i've been asking the network guy to run checks on the router, switch, etc for the past week or so but he seems to insist that it is highly unlikely anything would ever go wong with them.  being this the case, how do i go about finding out where this reset is coming from?
0
 
poliguinAuthor Commented:
it wasn't really the raid controller but rather high io that was causing the server to conk out on an intermittant basis.  it tended to be more intensive querries that were causing this problem most of the time.
0
 
arbertCommented:
Nice--glad someone else has verified this same problem :)  Just doesn't make sense to me why things are so quick to timeout in these scenarios...
0

Featured Post

Free Tool: Subnet Calculator

The subnet calculator helps you design networks by taking an IP address and network mask and returning information such as network, broadcast address, and host range.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

  • 4
  • 4
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now