I disagree with this and I haven't seen it in the real world.
basically.. a little bit of a memory leak isn't that big of a deal and
from where I am standing there is no ROI on making this change; and
thus becoming a slower developer-- because I've never had a problem
with ADO.
if you do the same thing in Access _ONCE_ with DAO you are going to get
a hang
I don't agree with this [...]; I don't need to explicitly close
anything.
As regards *closing*, I know from experience that letting a ADODB
Connection go out of scope will close the connection without problem
when using SQLNCLI, SQLOLEDB or Microsoft.Jet.OLEDB.4.0 but I don't
know whether this behaviour is ADO- or provider-specific.
As regards setting to Nothing, I am already in the habit of doing this
only when necessary. Consequently, I this code that frequently catches
my eye:
con.Close
Set con = Nothing ' release possible connection pooling
I suspect I had a problem once with connection pooling and the
'workaround' was to set the connection to Nothing, being something I
would not normally do. The aforementioned article seems to confirm
this.
In other words, there are exceptions to every rule and - don't take
this personally, it's not your fault - you sometimes have to do things
'manually'. Yes, you have to do this _all the time_ in DAO and in my
experience only very infrequently in ADO.
Other than that, you seem to have mistaken me for someone who uses DAO
but I accept your apology in advance ;-)
I am outraged that you [others] take your bad experiences with DAO
and transfer them to ADO and VB6.
Amen.
Jamie.
--
