none
[DBNETLIB][ConnectionWrite (send()).] errors

    Question

  • We have a Dell 2950 running Windows 2003 connecting to SQL2005 Database. 

     

    Users accessing their SQL application are getting this error message after leaving the application open for a period when they are not accessing the system.  We have run the application on two different servers and cannot re-create the errors, which might suggest a hardware problem with our server, but as yet we haven't identified the problem.

     

    Does anyone have any ideas ?

     

    Wednesday, May 23, 2007 11:30 AM

Answers

All replies

  • Hi Brian,

    I'm having similar issues with my system (new HP server running Win 2003 & SQL 2005 with VB App running on XP Clients, MDAC 2.81). Seems to affect certain PC's, doesn't affect a version of the VB 6 App running locally on the server, or one of the Clients that continually polls the server once per minute, 24/7.

    The error handling in the VB App actually writes a log of the error to a SQL Table, which suggests that the connection error occurs, and by the time the user confirms the msgbox prompt the connection comes back up, allowing the log to be written...

    I've tried disabling connection pooling in the ADO connection string & the SynAttackProtect REG setting change as discussed at http://www.eggheadcafe.com/ng/microsoft.public.sqlserver.connect/post22689813.asp

    Both to no avail....

    Was wondering if you'd found a resolution yet?


    Best regards

    Keith
    Thursday, June 14, 2007 11:56 AM
  • For your issue, I would try to follow the article http://support.microsoft.com/default.aspx?scid=kb;en-us;899599 to add the registry key. Maybe that will fix your problem. If not, please provide more information on the infrastructure to help us narrow the issue.

     

    HTH

     

    Thursday, June 14, 2007 11:05 PM
  • umm - our problem appeared to hardware - Dell announced urgent driver updates for the cards in our server, but that didn't entirley solve the problem although it is better. The the support desk for hte application we are using then recomended switching the server to use both TCP/IP and Named Pipes and then adjusting the client config appropriatly. this seems to have resolved our issue
    Tuesday, June 26, 2007 9:00 AM