Access won't close after referencing to another db (1 Viewer)

LPurvis

AWF VIP
Local time
Today, 10:07
Joined
Jun 16, 2008
Messages
1,269
Not wanting to labour this point... But to help reiterate to all why Chris and I are interested and were unconvinced of the regularity of this...
Considering the statement:
>> after looking at the code it was clear, at least to me (if not the others) that normally you don't have to worry about a database variable when it is referring to the current database, but when you are dealing with ANOTHER database then it is something completely different

I think it was clear to everyone, the intent of the suggestion.
We're all only too familiar with the "close objects you open" axiom. But it's a practice (some would say recommended practice - others would argue unecessary - others required :-s). But really little more than a rule of thumb.
There's no enforced guideline as to why this is.

It all comes down to implementation.

Suppose I write a COM interface for some groovy data access tool. Let's call it BAO.
I provide various methods for the objects in its library. One of which is a Close method. Now this is just a method like any other, I could have easily omitted it altogether but I chose to offer it because I want to perform some disconnection in there after which the object isn't active.
Equally I could have created the method's interface and completely forgotten to implement it or changed my mind at the last minute about disconnection and left the method in place to maintain binary compatabbility but it effective does nothing.
Equally I could have messed up hugely and implemented the disconnection code in the Requery method!
However it's very likely (if I'm at all competant - ahem) that I've performed some rigorous cleanup in the object's Terminatation.

I'm sure that DAO is much better written than BAO (it sounds pretty crap to me so far anyway).
DAO implements all its methods for a purpose and has evolved over time to improve bugs.
But ultimately the implemented methods don't reflect what actually happens. We don't know what happens.

The long standing theory is that VBA's garbage collection will destroy the object when it drops out of scope. (Debate will rage on about the validity of that - memory leaks occcur but finger pointing is futile without hard evidence).
If BAO's termination is efficient - the object should be equally efficiently destroyed.
I could choose to punish those interfacing with BAO they don't call the Close method explicitly. But, as I said, who's to say what actually put in there anyway - and is it itself not also prone to memory leaks?
Does my Termination code not perform the same task - assuming it's called at all by VBA properly destroying the object.

The answer to this is Null. (We don't know - we can't know).
Many of us implement what some consider good practices. Others choose not to (and there's lots of empirical evidence suggesting that they're not punished for doing so).
Finding repro's of memory leaks objects that won't shut down is the "golden egg".
Finding the reason for those is the answer.
OK - it'll still be empirical evidence (even cisrumstantial) unless MS open the source code for DAO. (My C skills would probably mean it was still a mystery lol).
Obviously that's not going to happen oohhh.... ever!
(I don't particularly blame them - I wouldn't either).

MS have addressed improvements in DAO over the years.
We can't say just how much changed in the move to... (I can't even bring myself to say its ridiculously long name) "ADE" in 2007.

It's not the case that every occasion of opening an external object demands that we call the Close method to allow it to perform effectively.
When I get the time I'll try to knock up a Reference equivalent of this example.
But I've had similar code tests before that didn't exhibit this behaviour.
But if I found a repro - rest assured the Test team would have it moments later. :)

Cheers.
 

Users who are viewing this thread

Top Bottom