Discussion :

[Largo38]

Bonjour,

une appli developpée sous Access 2007 me pose depuis quelques jours de gros soucis : je ne peux plus entrer en mode debug, cela fait instantanément planter Access.

Le contexte :
- une base splittée en frontale/dorsale, la dorsale ne contenant que des tables
- un formulaire avec plusieurs listes déroulantes permettant de choisir des critères.
- un bouton pour valider. Une fois validé, affichage d'un autre formulaire sur lequel on affiche les résultats en fonctions des critères sélectionnés.
- du code VBA rattaché au formulaire (contrôle des différentes valeurs sélectionnées sur les listes)
- un module VBA permettant d'alimenter le formulaire Résultat.

Du grand classique, quoi...
En mode "normal", l'appli fonctionne très bien, les résultats sont affichés correctement, RAS (si ce n'est quelques bugs résiduels, parfaitement de mon fait).

Le problème :
Si j'insère un point d'arrêt dans le code du formulaire de départ, tout va bien jusqu'à ce que le code "sorte" du formulaire :
- j'appelle l'ouverture du formulaire suivant (Application.DoCmd.OpenForm "FRM0_Result"), c'est ok.
- Le code entre alors dans le Form_Activate de FRM0_Result, je vois la 1ere ligne de code surlignée en jaune et... Access plante.

Si j'insère un point d'arrêt ailleurs (formulaire résultat ou module), Access plante (Microsoft Access a cesse de fonctionner) dès l'entrée dans le debogueur.

Conclusion :
Ca craint ! J'ai beaucoup de mal a écrire des requetes SQL en partie paramétrées si je ne peux pas suivre certaines variables... mais surtout je ne peux pas deboguer quand il y a un soucis.

L'observateur d'évènement indique effectivement une erreur :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
Nom de l’application défaillante MSACCESS.EXE, version : 12.0.6606.1000, horodatage : 0x4e27ab6b
Nom du module défaillant : MSACCESS.EXE, version : 12.0.6606.1000, horodatage : 0x4e27ab6b
Code d’exception : 0xc0000005
Décalage d’erreur : 0x0057a6bb
ID du processus défaillant : 0xb3c4
Heure de début de l’application défaillante : 0x01cee08922d4a238
Chemin d’accès de l’application défaillante : C:\Program Files (x86)\Microsoft Office\Office12\MSACCESS.EXE
Chemin d’accès du module défaillant: C:\Program Files (x86)\Microsoft Office\Office12\MSACCESS.EXE

J'ai bien évidemment farfouillé les forums ici et là, sans trouver de problème similaire, le code exception 0xc0000005 semble assez générique ; j'ai compacté la base ; j'ai créé une copie de sauvegarde (en passant par le menu Access kivabien) ; sur les conseils d'un collègue, j'ai créé une nouvelle base, recréé les liens externes, recréé les modules (un par un, par copier/coller du code), importé les formulaires : tout ceci n'a rien changé.

J'ai testé et reproduit le problème sur un poste Windows XP (32 bits)/Access 2007 (32 bits) et un poste Windows 7 64bits/Access 2007 (32 bits) : le problème se répète sur les 2 plateformes.


Auriez-vous une idée, voire une simple piste, pour refaire tomber en marche ce debogueur ?
En vous remerciant par avance pour vos lumières,
Largo

[marot_r]

De manière général ton code compile-t'il sans erreur ? Si non, règle ces erreurs en priorité ou mets le code fautif en commentaire.

Ensuite tu peux essayer un /Decompile c'est un paramètre non documenté de la ligne de commande qui enlève le code qui est créé en tâche de fond.

Tu peux aussi essayer de détruire le formulaire qui t'embête et le recréer.

Si tu as accès à un autre poste, fait créer une base vide sur ce poste puis importe tous les objets de la BD qui plante dans la base vide.

A+

[Largo38]

De manière général ton code compile-t'il sans erreur ? Si non, règle ces erreurs en priorité ou mets le code fautif en commentaire.

Oui, il compile sans erreur

Ensuite tu peux essayer un /Decompile c'est un paramètre non documenté de la ligne de commande qui enlève le code qui est créé en tâche de fond.

Ce paramètre est à ajouter à la ligne de commande d'Access ? Ca me permettra de démontrer quoi ?

Tu peux aussi essayer de détruire le formulaire qui t'embête et le recréer.

Il est relativement lourd, avec un graphique, 1 a 3 sous-formulaires avec des formats conditionnels, si je pouvais éviter... Mais je sens que je vais devoir y passer

Si tu as accès à un autre poste, fait créer une base vide sur ce poste puis importe tous les objets de la BD qui plante dans la base vide.

A+

Je l'ai fait sur le même poste, je le referrai demain sur mon poste en Windows XP.

Merci pour ces pistes

[marot_r]

Citation:
Ensuite tu peux essayer un /Decompile c'est un paramètre non documenté de la ligne de commande qui enlève le code qui est créé en tâche de fond.

Ce paramètre est à ajouter à la ligne de commande d'Access ? Ca me permettra de démontrer quoi ?

Une fois ta base "décompliée", tu peux la recompiler. Parfois le code compilé accumule des "cochoneries" et plante l'application. La décompilation permet de repartir à blanc.

Fait une recherche sur Google pour voir comment te servir de Decompile.

A+

[Largo38]

J'ai donc fait une décompile, suivi d'un compactage, comme conseillé chépluoù, sans succès.
J'ai copié le code du module (où le debugeur plante systématiquement en entrant) dans un éditeur de texte (Notepad++), ai supprimé le module, compacté la base, recrée un module, copié le code depuis Notepad++ et collé dans ce nouveau module. Pareil
Il me reste donc a faire pareil avec tous les modules et tous les formulaires ?

[loufab]

Bonjour,

Pour éviter de perdre du temps et vu le type de message je tenterais de faire la manip sur un autre poste. Si ça fait pareil c'est le fichier sinon... ben forcément c'est que le poste est pourri.

Cordialement,

[Largo38]

Bonjour,
...je tenterais de faire la manip sur un autre poste. Si ça fait pareil c'est le fichier sinon... ben forcément c'est que le poste est pourri...

Comme je le disais dans mon 1er poste :

J'ai testé et reproduit le problème sur un poste Windows XP (32 bits)/Access 2007 (32 bits) et un poste Windows 7 64bits/Access 2007 (32 bits) : le problème se répète sur les 2 plateformes.

Je n'ai pas retesté après décompilation, mais, comme ca n'a rien changé sur le windows7 64, j'avoue ne pas avoir refait le test sous XP/32.
C'est donc le fichier, mais, quoi et où...???

[marot_r]

Le décompile n'est pas une solution à tous les problèmes, hélas.

Essaye sur ton poste en XP.

A+

[loufab]

A Vérifier que l'office soit bien à jour avec le dernier SP.

A vérifier également : la présence d'un caractère de contrôle invisible, dans le code. J'ai déjà eu le cas avec code issue d'un copier/coller (source douteuse).
Pour vérifier ça, fait un export dans un fichier texte et vérifie le fichier avec Notepad++.

Si ça ne résout rien :

Crée un nouveau fichier ACCESS et importe toute l'appli à part le formulaire qui pose problème. Puis copie le formulaire sans le code (module = false), puis ensuite le code que tu auras précédemment enregistré dans le fichier texte, remettre le module = true avant .

Si ça ce produit toujours il faut envisager d'aller faire cramer un cierge à l'église la plus proche ou de sacrifier d'un poulet ou deux... ça ne sert à rien mais ça occupe.

[Largo38]

Merci pour ces suggestions et désolé pour le retour tardif.

j'ai cru un moment que le pb se situait dans le code appelé par le formulaire. En fait, c'est effectivement un formulaire qui fait planter. Tant que je reste dans les modules "standards" ou dans le formulaire appelant, ca marche. Dès que j'entre dans le code du formulaire, ca plante.

Donc, je suis tes conseils :

A Vérifier que l'office soit bien à jour avec le dernier SP.

C'est le cas

A vérifier également : la présence d'un caractère de contrôle invisible, dans le code. J'ai déjà eu le cas avec code issue d'un copier/coller (source douteuse).
Pour vérifier ça, fait un export dans un fichier texte et vérifie le fichier avec Notepad++.

J'avais déjà fais cette verif au niveau du module. Je viens de recommencer au niveau du code du formulaire : rien vu d'autre que des CR/LF.J'ai toutefois fait le copier/coller de NotePad -> Acces : idem.

Si ça ne résout rien :

Crée un nouveau fichier ACCESS et importe toute l'appli à part le formulaire qui pose problème. Puis copie le formulaire sans le code (module = false), puis ensuite le code que tu auras précédemment enregistré dans le fichier texte, remettre le module = true avant .

J'ai donc utilisé cette méthode (retrouvée aussi ici en cherchant comment mettre Module = false), avec export du code dans un .cls, ouverture du .cls sous NotePad++, réactivé le Module = true, copié/collé le code depuis le .cls ouvert dans NP++, ce, pour le formulaire appelant (qui a priori ne pose pas de pb, mais sait-on jamais) et le formulaire fautif, et...

Si ça ce produit toujours il faut envisager d'aller faire cramer un cierge à l'église la plus proche ou de sacrifier d'un poulet ou deux... ça ne sert à rien mais ça occupe.

faut que je trouve une église et quelques poulets, car ca plante toujours ...

[marot_r]

J'ai eu un cas semblable, la seulle solution que j'ai trouvée c'est d'arracher le formulaire fautif, compacter la BD et de recréér le formulaire ... pas cool :-(.

A+

[loufab]

Effectivement je plussois marot.
Suppression du formulaire et recréation. C'est pour cela que j'essai de faire des sauvegardes régulières en cours de dev. Avant chaque livraison systématiquement et lors de grosse évol ou modif.

[Largo38]

Bon, je sais ce qu'il me reste à faire... Vraiment pas cool...

Y'a pas moyen d'exporter le layout du formulaire, pour éviter de noter tous les noms, positions,... ?

[marot_r]

Tu pourrais simplement essayer un copier coller de tous les contrôles du formulaire de la BD qui plante à la nouvelle BD

Sinon un export en fichier texte mais je ne suis pas sur que cela marche.

A+