Home > Archive > Visual Basic Database > May 2005 > MDAC question
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
|
| I have an application that has two physical tiers.
The application server runs VB6 code.
The data server runs SQLServer 2000 (standard).
Now and again, I get the following error reported:
error -2147467259 - [DBNETLIB][ConnectionRead (recv()).]General network
error.
Searching the internet, I came across the following document
http://support.microsoft.com/kb/q175264/
This article implied that the commandtimeout value should not be set to 0
because of a bug in ADO 2.5. I think that timeouts should never be
infinite, but hey, that's the code I've inherited....
Anyhow, before changing all the VB code to use finite timeouts, I noted that
this article stated that the problem was fixed in MDAC 2.6. I therefore
decided to check the MDAC versions on my two physical servers.
Application Server: MDAC 2.71.9040.2
Data Server: MDAC 2.80.1022.0
I therefore have several questions:
1 - Is having two different versions of MDAC on the two tiers likely to
cause a problem? How about with these particular versions.
2 - If different MDAC versions can cause problems, could they cause the
ConnectionRead problem I'm experiencing.
3 - If I wish to standardise on one version of MDAC, is this a risk-free
upgrade?
4 - MDAC may not be my problem - anyone experienced the error I've had
before and fixed it? I can provide more details if required.
Many thanks in advance
Griff
| |
|
|
"Griff" <Howling@The.Moon> wrote in message
news:OLS3Rhl8EHA.1400@TK2MSFTNGP11.phx.gbl...
> I have an application that has two physical tiers.
>
> The application server runs VB6 code.
> The data server runs SQLServer 2000 (standard).
>
> Now and again, I get the following error reported:
>
> error -2147467259 - [DBNETLIB][ConnectionRead (recv()).]General
network
> error.
>
> Searching the internet, I came across the following document
>
> http://support.microsoft.com/kb/q175264/
>
> This article implied that the commandtimeout value should not be set to 0
> because of a bug in ADO 2.5. I think that timeouts should never be
> infinite, but hey, that's the code I've inherited....
>
> Anyhow, before changing all the VB code to use finite timeouts, I noted
that
> this article stated that the problem was fixed in MDAC 2.6. I therefore
> decided to check the MDAC versions on my two physical servers.
>
> Application Server: MDAC 2.71.9040.2
> Data Server: MDAC 2.80.1022.0
>
> I therefore have several questions:
>
> 1 - Is having two different versions of MDAC on the two tiers likely to
> cause a problem? How about with these particular versions.
>
> 2 - If different MDAC versions can cause problems, could they cause the
> ConnectionRead problem I'm experiencing.
>
> 3 - If I wish to standardise on one version of MDAC, is this a risk-free
> upgrade?
>
> 4 - MDAC may not be my problem - anyone experienced the error I've had
> before and fixed it? I can provide more details if required.
>
> Many thanks in advance
>
> Griff
>
First of all you are missing a major part of the question - what versions of
the ADO Data library are your applications using? What provider/driver
version are you using? The MDAC downloads are labeled by the highest/newest
ADO library supported but within its 50+ files is included all the earlier
versions. Newer features are supported in the newer Interfaces, but some
'bug fixes' are reflected in older ADO versions.
Having a different version of the MDAC components is likely not a problem -
as the ADO version you are using is obviously present or you would be
experiencing another problem (component not found). For example, I doubt
there is much difference between the ADO 2.6 data library supported by the
components in MDAC 2.7 and MDAC 2.8.
In general it is best to keep all of your MDAC components up-to-date with
the latest versions. But is that "risk free"? Nothing is absolutely
risk-free when it comes to changing out COM components. However, the MDAC
and ADO is one of the best 'COM' success stories out there. I have used a
policy of always upgrading servers and workstations to the latest MDAC as
part of a regular maintenance schedule and have only been burnt a couple of
times. [Of course, with a critical mission application/server this policy
may not be appropriate and possilbly job-threatening. <g>]
As for your network error, you will need to dig deeper than the ADO data
library version, and no simple answer is available without knowing more
about YOUR problem domain. I suggested that the ADO data library is likely
not the cause since ConnectionRead is called by drivers and providers.
Are you doing something cute with your connections - custom pooling, not
catching timeouts, errors, or other events?
Are you possibly blowing away connections without letting the server know?
Are you letting a connection 'hang-out' there for ever?
Have you enumerated the entire ADO Errors collection to make sure no other
information is available.
hth
-ralph
| |
|
| > First of all you are missing a major part of the question - what versions
of
> the ADO Data library are your applications using? What provider/driver
> version are you using? The MDAC downloads are labeled by the
highest/newest
> ADO library supported but within its 50+ files is included all the earlier
> versions. Newer features are supported in the newer Interfaces, but some
> 'bug fixes' are reflected in older ADO versions.
I wish I knew for sure. The VB6 application was written by a web developer,
so the code uses create object commands rather than using project
references:
Set oConnection = CreateObject("ADODB.Connection")
How can I tell for sure...is it the version of the "m ox.dll" or
"mo15.dll" or something else that I would need to check?
> In general it is best to keep all of your MDAC components up-to-date with
> the latest versions. But is that "risk free"? Nothing is absolutely
> risk-free when it comes to changing out COM components. However, the MDAC
> and ADO is one of the best 'COM' success stories out there. I have used a
> policy of always upgrading servers and workstations to the latest MDAC as
> part of a regular maintenance schedule and have only been burnt a couple
of
> times. [Of course, with a critical mission application/server this policy
> may not be appropriate and possilbly job-threatening. <g>]
Just out of interest, what steps do you suggest one should take to ensure
one doesn't get "burnt"?
> As for your network error, you will need to dig deeper than the ADO data
> library version, and no simple answer is available without knowing more
> about YOUR problem domain. I suggested that the ADO data library is likely
> not the cause since ConnectionRead is called by drivers and providers.
okay.
> Are you doing something cute with your connections - custom pooling, not
> catching timeouts, errors, or other events?
> Are you possibly blowing away connections without letting the server know?
> Are you letting a connection 'hang-out' there for ever?
> Have you enumerated the entire ADO Errors collection to make sure no other
> information is available.
I don't think that the original developer was doing anything particularly
out of the ordinary (apart from approaching it from a VBScript point of
view). He simply created a connection object and set its connection time
out and command time out values to 0 (infinite) and then repeatedly called
the .Execute method on them to fire SQL statements at SQLServer.
> hth
> -ralph
Griff
| |
|
| > First of all you are missing a major part of the question - what versions
of
> the ADO Data library are your applications using?
Checked the ADO version by creating an ADODB.Connection object and checking
the reported VERSION property.
The application tier is running ADO 2.7
The data tier is running ADO 2.8.
> What provider/driver version are you using?
The provider is SQLOLEDB:
obConnection.Open "Provider=SQLOLEDB;Persist Security Info=False;" &
"Server=" & sConnectionServer & ";Initial Catalog=" & sDatabaseName,
sConnectionUsername, sConnectionPassword
I don't know what driver version this is.... Should I be using
"Provider=SQLOLEDB.1" ?
Just to confirm, this is a VB6 application, not .NET.
Griff
| |
|
|
"Griff" <Howling@The.Moon> wrote in message
news:%23CxO35n8EHA.2012@TK2MSFTNGP15.phx.gbl...
versions[color=darkred]
> of
> highest/newest
earlier[color=darkred]
>
> I wish I knew for sure. The VB6 application was written by a web
developer,
> so the code uses create object commands rather than using project
> references:
>
> Set oConnection = CreateObject("ADODB.Connection")
>
> How can I tell for sure...is it the version of the "mox.dll" or
> "mo15.dll" or something else that I would need to check?
>
with[color=darkred]
MDAC[color=darkred]
a[color=darkred]
as[color=darkred]
> of
policy[color=darkred]
>
> Just out of interest, what steps do you suggest one should take to ensure
> one doesn't get "burnt"?
>
likely[color=darkred]
>
> okay.
>
know?[color=darkred]
other[color=darkred]
>
> I don't think that the original developer was doing anything particularly
> out of the ordinary (apart from approaching it from a VBScript point of
> view). He simply created a connection object and set its connection time
> out and command time out values to 0 (infinite) and then repeatedly called
> the .Execute method on them to fire SQL statements at SQLServer.
>
>
> Griff
>
>
1) Debug.Print "The version is " & oConnection.Version
2) I haven't yet discovered a magic spell to avoid getting 'burnt'. (Wish I
had - I would be laying on a beach right now, sipping exotic drinks and
surrounded by nubile natives, rather than in a cubical watching the cold
rain coming down.) You just have to test.
3) The only article I could find relating to a "General Network Error" was
this...
http://support.microsoft.com/defaul...kb;en-us;229564
Are you using an OLE DB provider? I would try turning 'connection pooling'
off and see what happens. Connection pooling is just the kind of 'hidden'
'helpful' service that would likely blow-up at the wrong time. <g>
I piddled about on Google for awhile (I am sure you have tried this as well)
and there doesn't seem to be any specific cause or cure for a "General
Network Error". Again turning pooling off seems to be the most commonly
listed solution. Others have suggested setting the pool count to a specific
number (opposed to the default). One poster offered that his problem was
solved by setting a specific timeout value. ?????
I have never run into this specific error myself. But, for even marginally
complicated applications I tend to use MTS/COM+. While over-kill in many
cases it does provide a easy, controlled way to trap an error condition and
allow a graceful exit and redo. I have found that such conditions
unfortunately appear randomly over time with even the best of designs. Often
the exact cause is never really known, but it doesn't matter.
hth
-ralph
| |
|
| > 1) Debug.Print "The version is " & oConnection.Version
Yup - thanks
> 2) I haven't yet discovered a magic spell to avoid getting 'burnt'. (Wish
I
> had - I would be laying on a beach right now, sipping exotic drinks and
> surrounded by nubile natives, rather than in a cubical watching the cold
> rain coming down.) You just have to test.
Thought that might be the case....looks like I'll be crossing my fingers
then.
> 3) The only article I could find relating to a "General Network Error" was
> this...
> http://support.microsoft.com/defaul...kb;en-us;229564
> Are you using an OLE DB provider? I would try turning 'connection pooling'
> off and see what happens. Connection pooling is just the kind of 'hidden'
> 'helpful' service that would likely blow-up at the wrong time. <g>
The provider I'm using is SQLOLEDB. I've seen examples using SQLOLEDB.1,
not sure if this is the preferred choice now?
> I piddled about on Google for awhile (I am sure you have tried this as
well)
> and there doesn't seem to be any specific cause or cure for a "General
> Network Error". Again turning pooling off seems to be the most commonly
> listed solution. Others have suggested setting the pool count to a
specific
> number (opposed to the default). One poster offered that his problem was
> solved by setting a specific timeout value. ?????
I think Google must have been hit hard yesterday :-)
The specific timeout vs infinite timeouts appear to be a problem up to ADO
2.5. See the link in my previous post. I am tempted though to remove our
infinite timeouts to finite ones since I don't like the idea of something
waiting for every.
My gut feeling though is that it isn't a time-out problem. I'm sure that
it's happy to wait forever for SQLServer to return something, but to my mind
it's like having an open connection to SQLServer and then not being able to
find that anymore.
> I have never run into this specific error myself. But, for even marginally
> complicated applications I tend to use MTS/COM+. While over-kill in many
> cases it does provide a easy, controlled way to trap an error condition
and
> allow a graceful exit and redo. I have found that such conditions
> unfortunately appear randomly over time with even the best of designs.
Often
> the exact cause is never really known, but it doesn't matter.
This really is a nasty program I've inherited and I'd love to re-write it
from scratch in COM+. But I'd prefer even more to be on my own beach right
now, exotic drinks etc.
> hth
It does, thanks
Griff
| |
| SteveBlack 2005-05-05, 11:02 pm |
| I'm also having difficulty with this error.
In my research it appears that it mostly occurs with separated hardware talking through load balancing devices or software.
I'm trying to isolate this as a definate cause. Could you assist by indicating if there is some a connection management scenario in play here?
Thanks
Steve |
|
|
|
|