WOW TONY YOU ARE A WORK OF FOCKING ART
you just said 'oh it has nothing to do with ADO' and then you pointed
out the EXACT JET BUG I was referring to
IN OTHER WORDS-- TONY IS SAYING 'AARON IS RIGHT, IT IS A DAO BUG'.
Rational people-- when they see a piece of shit library that makes
them de-instantiate variables-- they move up to a real library like
ADO
-------------------------------------------------------------------------------------------------------------------
Bugs: Access minimizes to Windows 95/NT toolbar instead of closing
Author(s)
Michael Kaplan
(Q) Whenever I try to close Access, it minimizes itself to the
taskbar instead of closing. What's causing this to happen?
(A) This happens whenever you don't destroy DAO references that you
might have set up through code. So while other refs (like forms) are
good programming practice to clean up, closing DAO references will
solve this problem.
VBA is documented as being a good policeman in closing down object
references when the variable that contains them goes out of scope.
When an OLE Server is properly designed, its AddRef and Release counts
should make sure that it knows exactly how many people are referencing
it at all times. HOWEVER, due to the complex interactions of VBA, Jet,
DAO, and Access, there are times, especially in complicated DAO code
involving transactions, that an object pointer goes out of scope
without DAO being informed of its release. This orphan pointer is a
BUG but it is (as you might imagine) a very hard bug to find and track
down. Six such bugs were fixed before Access 97 shipped and at least
two were identified after that (both involve using RecordsetClones and
both have no workarounds other than not using the clone).
The source of the bug is that Access, which contains that handy
DBEngine reference you have been using (and which uses it itself for
various things, including wizards and recordsetclones), will not shut
down while there are more calls to AddRef on DAO objects than
Release.There are two workarounds:
1) Always shut down explicitly everything you open. This means in
the DAO case that you should close it if you opened it, then set it to
Nothing. As a rule you should not close what you did not open (there
are other bugs related to that which are beyond the scope of
discussion here), but everything should be set to nothing. For
example:
set myRS = Currentdb.OpenRecord("SomeTable",dbOpenDynaset)
'.... plenty of good stuff here
set myRS=Nothing
The reason this often fixes the problem is that by changing the order
of when things are freed you often find that the conflicts go away,
and VBA implicit freeing of object pointers does not error when it
fails, it just assumes life is hunky-dorry.
2) Make your own DBEngine and just stop using the Access one. You
can do this by either calling CreateObject on DAO.DBEngine.35 or by
dimming a DBEngine variable like: Dim dbe as New PrivDBEngine This
DBEngine will not be checked by Access before it shuts down to see if
it still in use.
