Make your own free website on Tripod.com

 

Home
Home

---Soumis par Michael Kaplan---

Access se minimise sur le toolbar de Windows 95/NT au lieu de se fermer totalement.

(Q)    Quand j'essaie de fermer Access, il se minimise sur le toolbar plutôt que de se fermer. Qelle en est la cause?

(A)    Cela arrive quand vous ne détruisez pas une référence DAO que vous avez créé depuis votre code. Même si le nettoyage de d'autres type de références (tel que de formulaires), fermer celles de DAO résoud ce problème.
    Il est documenté que VBA est un bon gendarme en fermant les variables qui sortent de leur portée (scope). Lorsqu'un serveur OLE est proprement construit, il décompte les utilisations de par AddRef et Release, de sorte à savoir si il possède encore des utilisateurs, en progression dans le temps. Cependant, dû à des interractions complexes entre VBA, Jet, DAO et Access, il arrive, principalement au travers de transactions complexes, qu'un objet se retrouve hors-portée sans que DAO n'en soit informé. Cet orphelin est un BUG, mais c'en est un qui est très difficile à retracer. Six d'entre eux furent repérés avant la publication définitive de Access 97, et au moins deux autres furent trouvés par la suite (tous deux impliquant des RecordsetClones et tous deux n'ayant de solution que d'éviter d'utiliser un).
    La source de ce bug est qu'Access, fournissant une référence utile à DBEngine, elle-même utilisée à diverses fins, par les "wizards" (assistants) et par les recordsetclones, ne se termine pas lorsqu'elle se retrouve avec plus de AddRef sur un objet DAO, que de Release. Il y a deux façons de contourner le tout:
   
    1) Toujours fermer ce que vous ouvrez. Entre autre, pour DAO, vous devez fermer l'objet si vous l'avez ouvert, puis l'assigner à Nothing. Comme règle, ne pas fermer ce que vous n'avez pas ouvert (d'autres bugs seraient reliés à ce cas, mais en dehors de la discussion qui nous préoccupe). Example:
    set myRS = Currentdb.OpenRecord("SomeTable",dbOpenDynaset)
    '.... de bonnes choses, en masse...
    set myRS=Nothing

Le problème se trouve réglé de par ce que l'ordre de "libération" des objets se trouve modifié, alors qu'un simple relâchement par VBA trouvant la fin d'une portée (scope) produirait éventuellement un conflit de décomptes. 

    2) Fabriquer votre propre  DBEngine et cesser d'utiliser celui de Access. On peut faire la chose avec un appel à  CreateObject sur DAO.DBEngine.35 ou en déclarant une variable tel que: Dim dbe as New PrivDBEngine. Ce DBEngine ne sera pas vérifié par Access lors de la demande de fermeture.

-- Addendum

   Microsoft a confirmé qu'il s'agit bien d'un bug en Access 97.  

    Unable to quit Microsoft Access

    Le problème est causé par le code du sous-formulaire qui se réfère à une valeur booléenne d'un contrôle dans le formulaire parent lorsqu'il évalue l'énoncé If:

    If me.Parent!chkSomeCheckBox then

    Une solution est de comparer explicitement à True/False:

    If me.Parent!chkSomeCheckBox = True then

-- De Arvin Meyer

    Ce bug booléen peut se produire que le contôle référé est sur le sous-formulaire ou pas, et pour quelque contrôle sur le formulaire, et qu'il soit ou non sur le sous-formulaire, s'il refère au formulaire principal. 

If Me.chkBool Then 

peut produire ce bug, peu importe où il apparaît, ou ce à quoi il refère.