Re: MDAC question
From: Ralph (msnews.20.nt_consulting32_at_spamgourmet.com)
Date: 01/04/05
- Next message: Paul Clement: "Re: "Send/Receive" in Outlook from VB"
- Previous message: Bob Butler: "Re: Detecting windows shutting down possible?"
- In reply to: Griff: "Re: MDAC question"
- Next in thread: Griff: "Re: MDAC question"
- Reply: Griff: "Re: MDAC question"
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 4 Jan 2005 12:09:52 -0600
"Griff" <Howling@The.Moon> wrote in message
news:%23CxO35n8EHA.2012@TK2MSFTNGP15.phx.gbl...
> > 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 "msadox.dll" or
> "msado15.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
>
>
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/default.aspx?scid=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
- Next message: Paul Clement: "Re: "Send/Receive" in Outlook from VB"
- Previous message: Bob Butler: "Re: Detecting windows shutting down possible?"
- In reply to: Griff: "Re: MDAC question"
- Next in thread: Griff: "Re: MDAC question"
- Reply: Griff: "Re: MDAC question"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
|
