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