|
(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.
- Addendum
Microsoft has confirmed this to be a bug in Access 97.
Unable to quit Microsoft Access
The problem is caused by code behind a subform which references a
boolean control on the main form and evaluates it in an If Then statement as
If me.Parent!chkSomeCheckBox then
The resolution is to do the True/False comparison explicitly.
If me.Parent!chkSomeCheckBox = True then
- From Arvin Meyer
The boolean bug can occur whether or not the control is on a
subform, and whether
or not if on a subform, it refers to the main form.
If Me.chkBool Then
can trigger
the bug, no matter where it occurs, or what it refers to.
|
