-2147467259 - [DBNETLIB][ConnectionWrite (send()).]General network error. Check your network documentation
-
I Have SQL Express installed on 17 ships. Each ship has a VB6 Client application using OLEDB to connect to the database on local machine. Other workstations on network also connect - we think without error. The error above is thrown on 4 of the 17 ships. The workstations acting as the file server are supposed to be identical (Windows XP).
We have been assured that all poer save settings on LAN Card and motherboard have been disabled.
If I google on this error, I get over 100 hits going back several years ! Ideas to fix have included turning off connection pooling and using TCPIP instead of Named Pipes on client workstation where database server and application are running.
Any other ideas on what could cause this, or why 13 machines are OK, but 4 are not ? Thanks.
-
Have been getting this error sporadically for years on a large SS2K site. Fortunately, it does not happen that often. But, in my case, it is mostly associated with something that goes through ADO+ODBC using TCP/IP. For a long time our software was blamed on it until I wrote a simple VB script routine that runs in a loop and remains permanently connected and executes a simple 'select 0' every mìnute. When an error occured it would get logged and then attempt to re-establish the connection.
The ADO Err stack always had two errors with the second one always being 'General network error'. The first error would vary including your 'ConnectionWrite(Send())'.
Now the problem was squarely in Microsoft's terrrory. This problem was never solved. We checked the hardware, routers, service packs - you name it. We even ran the script on the database server itself and it would happen there as well.
-
By far this is the most frustrating issue that I have been dealing with lately!!
We have a number of Services that connect to a SQL 2005 Database via OLEDB/ADO. We are seeing these "General Network" Errors all the time recently. We have checked hardware, software, Database Settings you name it. Nothing seems to be able to shake this.
The network admins are insulted that we even suggest that there might be a problem with the network, but what else can we say? They of course have not suggested any better solution.
Michael, you said that it's squarely in Mico$oft's territory now? Did you open an incident on this? Where is it now?
Regards, Irish
-
Thanks for the comments. I think opening up an incident with Microsoft is best idea here. Too bad, SQL Express is a really nice product - but if it can't be made reliable...that certainly is an issue...
-
At the time an incident was opened but I think the client I worked for at the time then dropped it. The problem still occurs today but apparently with a frequency sufficiently low to be ignored by everyone.
-
We are sending technician to one ship that has it bad and reinstall SQL Express 2005, make sure the most recent version is installed. Customer will loom to replace the workstation (XP) that holds the database.
-
Read the KB article in the link below. It gives a solution for you. http://support.microsoft.com/kb/303120/
Cheers,
Sugeshkumar Rajendran
SQL Server MVP
http://sugeshkr.blogspot.com -
Unfortnately thr service pack is for SQL Server 2000, while the database engine is SQL Express 2005.
We sent technician to ship; uninstalled/reinstalled. Looked ok until he left ship, then original problem resumes.
One note of interest, he had some trouble with .NET Framework 2.0 and had to reinstall that. So maybe "Assembly Hell" replaces "DLL Hell" ?
In any event, still no solution. During SQL installation the message was displayed that computer does not meet requirements...but those messages have been ignored up til now because no details are given and most computers work fine.
-
We are still working on this one. From what we have been able to discern, it appears to be the combination of SQL 2005 SP2 and 2003 SP2. The investigation is on-going. Thus far the Microsoft representation we have gotten has been unimpressive.
Regards, Irish
-
I'm seeing this on SQL 2005, SQL 2000 - on both Windows XP and Windows Server 2003.
I can reproduce the problem reliably, but using our rather large ERP software (that we develop). I'm working on a small test app which will also reproduce the problem, such that I can raise a support issue with Microsoft. Being in software, I understand the importance of giving them something they can use to reliably reproduce the problem.
It seems to be (for us, anyway), when an ADO (OLEDB) connection is busy waiting for the server (in our case a long running stored procedure to return results to a Crystal Report), a second, separate OLEDB connection attempts to fire some queries against the same server. In my tests these queries are merely SELECT statements - which surprised me - given the error message returned was a ConnectionWrite send() error - nothing's trying to write, so I suspect ConnectionWrite is referring to not a SQL Write (ie UPDATE / INSERT / DELETE), but a network connection to the SQL Server (think socket comms).
I thought it may have been related to connection pooling (as this was the only way I could see how one ADO connection could be affecting another), so I made sure the second connection to use different SQL credentials - this should make the two connections forced into separate pools - as the connection string is what is used to pool connections together. Anyway - the problem still occurs with connection pooling out of the equation.
Like I mentioned earlier, we use two ADO connections in our software - one for reporting, one for the application - and usually the reporting ADO connection has different SQL credentials anyway (for security purposes). Now the Reporting connection is in fact used by Crystal Reports 11 - I'm *assuming* it's creating an OLEDB connection - as I've coded it to use the SQL OLEDB data provider. What other connection options Crystal decides to set is at present a complete mystery to me (In my experience Crystal can do bizarre things). First I'll try to reproduce the problem with Crystal out of the equation.
I also tried the SynAttackProtect registry hack (http://support.microsoft.com/default.aspx?scid=kb;en-us;899599) - this also had no effect.
We're a certified MS partner, and a certified MS ISV. If I can reproduce the problem reliable with a simple application I can provide to MS, I'll do my all to make sure we see a solution... and I'll be sure to post my progress with this issue here
-
Ok, I've made some discoveries.
It doesn't seem to be a SQL or OLEDB problem. It certainly seems to be (in my case, anyway) related to Crystal Reports.
I found the problem only occurs when a query is issued on one connection whilst a Crystal Application Object (CRAXDT Version 11) is waiting for a stored procedure based report to being returning results. The Crystal Application object must be in the same application domain as the application issuing the query which fails.
Changing the network protocol used by SQL to be named pipes instead of TCP/IP seemed to improve things - I no longer got the DBNETLIB error, but the Crystal Report Application threw errors when it's report finished (could be related, but with Crystal it's hard to know).
This problem seems to be only reproducible when you are able to execute a query concurrently to the Crystal Application object awaiting stored procedure results - I would have said "ie: multi-threaded applications", but our application is not multi-threaded - it's written in VB6 - but still we somehow are able to fire queries through our application despite the Crystal Application object awaiting results. Perhaps Crystal creates a new thread and runs in that ?
-
More discoveries.
I see this behaviour on SQL 2000 SP4, but not SQL 2000 with no SP's.
In my situation, SQL 2000 with no SP seems to cause my application to be "less threaded" - ie: any Reports running waiting for stored procs causes the whole application to "block" and wait - ie: nothing else within the application can be run.
However, SP4 of SQL 2000 and the behaviour changes - no longer is my application "blocked" - I can load other reports, navigate menu's, etc - and thus cause other queries to run and the DBNETLIB error occurs.
-
An email from a reader of this forum has prompted me to post my conclusions.
Firstly, to re-cap on how we got the errors - they only occurred when Crystal Reports 11 was busy running a query, and we attempted to issue a SQL query (using OLEDB) on a different connection, but a connection within the same application.
We never found a solution to this problem. We did however, discover how we were able to issue a query when our application should have been blocked and waiting for Crystal to finish (our app is in VB6 and thus single threaded).
We use the Catalyst Socket Control for some of our functionality, and that control being in the app caused it to behave in a multi-threaded fashion 'sometimes'. It seems that control gives the UI a degree of multi-threadedness (for want of a better term), and allowed the user to open forms, etc whilst waiting for a report and thus causing the subsequent errors.
From memory I believe we upgraded the control to the latest version, and the behaviour returned to what we had before - the UI does not respond whilst Crystal reports is running, and therefore no errors.
-
This may help, maybe related to a "security feature" of 2003 SP1 and SP2.
http://support.microsoft.com/default.aspx?scid=kb;en-us;899599
-
What we found was related to a security feature added in Windows 2003 Service Pack 2. It is something called TCP Chimney. It all cropped up after applying SP 2. Removing the Service Pack did not resolve the issue. What we found out later is that the feature was there with SP1, but was not enabled by default as it was in SP2. Removing SP2 did not revert the setting back. We eneded up making a change in the Registry to resolve this.
Here's more information:
http://www.microsoft.com/whdc/device/network/TCP_Chimney.mspx
http://msexchangeteam.com/archive/2007/07/18/446400.aspx
We issued the command "Netsh int ip set chimney DISABLED" and that made the issue go away for us.
Regards, Irish
Viewing 15 posts - 1 through 15 (of 37 total)
You must be logged in to reply to this topic. Login to reply