Re: MDAC question
From: Griff (Howling_at_The.Moon)
Date: 01/04/05
- Next message: Ralph: "Re: Connecting visual basic 5.0 to access 2003"
- Previous message: Ralph: "Re: MDAC question"
- In reply to: Ralph: "Re: MDAC question"
- Next in thread: Ralph: "Re: MDAC question"
- Reply: Ralph: "Re: MDAC question"
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 4 Jan 2005 16:57:20 -0000
> 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
- Next message: Ralph: "Re: Connecting visual basic 5.0 to access 2003"
- Previous message: Ralph: "Re: MDAC question"
- In reply to: Ralph: "Re: MDAC question"
- Next in thread: Ralph: "Re: MDAC question"
- Reply: Ralph: "Re: MDAC question"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|