Home  |  About  |   Search   

What's New
Table Of Contents
Credits
Netiquette
10 Commandments 
Bugs
Tables
Queries
Forms
Reports
Modules
APIs
Strings
Date/Time
General
Downloads
Resources
Search
Feedback
mvps.org

RunCommand Constants

Terms of Use


 

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.

- 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.


1998-2009, Dev Ashish & Arvin Meyer, All rights reserved. Optimized for Microsoft Internet Explorer