Discussion :

[Shoryu]

Bonjour
voila, ce post n'est pas vraiment une question technique, mais je m'adresse aux habitués d'access (experts, professionels, autres...) . Quand vous rencontrez un problème mais que vous ne savez pas d'ou cela vient, comment procedez vous? que verifiez vous en premier, quels reflexes avez vous?
je vous demande ca parce que j'ai parfois des problèmes tout simples (plutot liés a la manipulation d'access, erreurs d'etourderie etc...) mais je mets des heures à les retrouver, donc je perds beaucoup de temps...
je parle plutot des problèmes que le debogueur ne trouve pas des le debut, du genre que votre application se lance mais ca ne fait pas ce que vous voulez

en fait je sais jamais par ou commencer a chercher...

vous qui avez de l'experience, avez vous pas des conseils a me donner pour optimiser mon temps de recherche?

merci de votre aide ^^

[Bibicmoi]

Niveau expérience, je me pose pas trop là. Mais niveau erreur à la con ou programme qui marche pas, je suis un DIEU!!!!!!!
Si tu cherches à trouver des fautes de frrrrappe ou des fautes d'étourderie, c'est ce qui prend le plus de temps, car les moins évidentes (va voir que t'as oublié de mettre un ";" à la 14558392125° ligne de code!!).
Par contre, pour le reste, je fais systématiquement du pas à pas, en mettant au passage des petites msgbox pour voir si le programme rentre dans telle ou telle boucle, en mettant des "Stop" un peu partout (je dois encore en avoir qui traîne dans des programmes qui marchent nickel d'ailleurs!), en testant les valeurs qui me semblent déconner...
Je pense pas qu'il y ait beaucoup de secret en matière de debuggage : beaucoup de patience, de minutie et d'organisation.
Et puis, si jamais je trouve vraiment rien, après m'être cassé la truffe pendant 15 ans sur le même problème, je viens ici.
D'ailleurs, à ce propos, j'ai posté un problème ce matin et si tu pouvais....
Non, je déconne!

J'espère que ça pourra t'aider à la prochaine erreur ou au prochain problème, mais j'en doute sérieusement.
Ciao.

[Elmilouse]

A peu près pareil que Bibicmoi, je mets des msgbox un peu partout pour verifier a des moments clès du programme les valeurs des variables pour voir si elles ont bien les bonnes valeurs au bon moment

[Tan]

Alors ce que moi, je fais (en gros comme les deux autres messages mais bon)

1- Je mets option explicit en haut de chaque module, c'est plus performant et tu limites les fautes de frappe dans tes variables du style: monChamp.text = maVariabe au lieu de monChamp.text = maVariable

Tu perds pas de temps à chercher pour te rendre compte que rien n'est mis dans le champ text car il n'y a rien dans maVariabe (normal c'est une faute de frappe)

2- L'exécution pas à pas est quasiment le seul moyen de voir, où il y a un problème (s'il n'y a pas d'erreur, il s'agit souvent d'un problème qui nous échappe (raisonnement faux, mauvaise comprehension d'une fonction...)
Le pas à pas, montre où le programme ne fait pas ce que tu voulais

3- Dans le même principe que faire des msgbox, j'utilise debug.print, qui me permet de faire des tests sur des variables, passage dans boucle (plus rapide que le pas-à-pas (quand on a une idée du problème)...

4- Si j'ai des requêtes, je les récuoère (via debug.print) et je les test directement sous Access, les requêtes n'ont pas toujours le résultas que l'on souhaité

5- J'utilise des points d'arrêt (pour voir l'état des mes variables (j'ajoute des espions pour voir leurs valeurs))

6- Pour corriger les problèmes, il y a la fenêtre des variable local.

Donc, dans affichage: il y a fenêtre local, tu peux mettre les valeurs que tu veux dans des variables, pour faire des tests, fenêtre espion (permet de voir toutes les propriété des variables ou control: nom, valeur, backColor, item...). Et enfin, il y a aussi, la fenêtre Execution pour les résultat du debug.print.

Voilà, ce que je fais moi, mais sans erreur, (je me répette) la seule solution est le pas à pas (ou point d'arrêt).

Si tu ne trouve pas, tu cherche sur le net (notemment FAQ, et forum), et oublies pas l'aide ACCES aussi.

Salut...

[ypicot]

Pareil de Tan sur le principe, plus débogage / compiler. Il ne s'agit pas d'une véritable compilation, mais plutôt d'une vérification syntaxique de l'ensemble du code.

En fait, il y a pour moi deux façons d'utiliser le débogueur :
- soit tu appuies sans réfléchir sur la touche F8, en regardant d'un oeil bovin le curseur passer de ligne en ligne. Généralement, tu passes 20 fois sur l'erreur sans la voir...
- soit tu refléchis à ce que devrait faire la ligne de programme qui va s'exécuter (style, si tu as un if : "quelles sont les valeurs... est-ce que je vais dans le then ou dans le else"). Plus long à prioris, mais beaucoup plus efficace.

Sinon, j'utilise une approche avec utilisation intensive de jeu d'essais, car cela me permet de réfléchir avant à ce que doit faire la fonction. C'est du TDD (Test Driven Development)

Accessment,

Yvan

[vdbadr]

Perso lors des problemes je suis pas un pro (ni dans la progammation ni dans le langage vba) lors je fais comme les autres...
analyse rationelle et methodique en eliminant 1 a 1 les sources ou cause du probleme mais en tant que novice cela ce revele une tache ardue (mais cela meconforte quand je vois des ingenieurs informaticiens qui merdent lamantablement comme moi... )

Je pense que la resolution des problemes viens avec l'expérience, principale source, ma connaissance...

[muse19]

Moi j'ai découvert l'utilisation du déboggeur y'a pas longtemps, donc je suis adepte des msgbox à tout va, mais c'est quand même pénible.

Déjà pour éliminer les problèmes inhérents à la saisie des variables etc, j'utilise la complétion. Alors au cas où vous ne connaitriez pas (ce qui m'étonnerait) il s'agit de la combinasion Ctrl + Espace
Maintenant je me suis calmée sur les msgbox et je prends un petit papier (oui, c'est une regression dans l'arrière temps) et je réfléchis au scénario qui se déroule et pourquoi. Bref des techniques assez usuelles...


Voilà Bonne soirée

[Papy Turbo]

Sujet passionnant, et qui peut nous entraîner très loin...

du genre que votre application se lance mais ca ne fait pas ce que vous voulez

1ère réflexion : si tu es dans ce cas là, mettre un gros STOP dans ta tête, et suivre absolument la démarche de muse19 :

et je prends un petit papier (oui, c'est une regression dans l'arrière temps) et je réfléchis au scénario qui se déroule et pourquoi.

Ceci dit, je n'appellerais pas ça une régression, mais plutôt la pause indispensable.

Sinon, toutes les suggestions ci-dessus résument bien la démarche générale : des Stop, du pas à pas, test en fenête Exécution, debug.?, réfléchir, réfléchir et un petit peu aussi : réfléchir...
J'ajouterais juste 2 ou 3 notes :
- à la recherche d'un bug 'général' (tu ne sais pas dans quelle routine il est), j'aime bien la technique un peu médiévale de "l'étau qui se resserre sur la c..ille" (mesdames, mesdemoiselles, merci d'excuser ces termes techniques, que vous connaissez aussi bien que nous, ou mieux) :
++ mettre un Stop avant l'erreur, éventuellement sur la 1ère ligne de code de l'appli, mais alors que toutes variables sont OK,
++ un autre au delà : fin du Form_Load du premier formulaire, par exemple, en tout cas dès que une erreur est constatée et sûre !
Progressivement, selon les cas, en faisant du pas à pas rapide (Maj+F8 ), descendre le 1er Stop ou remonter le second, jusqu'à coincer la ligne avant laquelle tout va bien, après laquelle ça plante.
- si tu décomposes tout ton code en routines (Sub/Fonctions) courtes (en général : pas + d'un écran chacune. T'as un 21 pouces ? tant pis pour toi ) et déboguées au fur et à mesure, ce genre de recherche doit diparaître (quasiment) pour toujours
Le simple fait d'écrire 2 ou 3 subs sans les déboguer à fond, est signe que tu vas trop vite et tu vas te noyer...

- autre règle assez fréquente : ne jamais poursuivre 2 lièvres à la fois ! En clair, résoudre un bug à la fois, le premier que tu as levé -> dans la plupart des cas, de nombreux autres "bugs", ou messages d'erreur, disparaîtront

Enfin, en cas de désespoir, réécrire tout en essayant de simplifier au maximum : pareil, ça t'oblige à tout revoir, tout réanalyser en détail, mettre des noms de variables de plus en plus clairs et explicites (et utiliser Ctrl+Espace si les noms sont longs, comme suggère encore muse19, tu es sûr de ne pas te tromper). Quand on veut faire chic, on appelle ça du "re-engineering" 8) .

[moq]

Moi tout pareil.

Par contre, quand le problème se produit sur un code que j'ai écris plusieurs mois avant, là ça devient très galère. Arrive les questions "Comment ça marche ce que j'ai écris ? J'ai écris ça moi ?". D'où l'importance de bien commenter son code et d'en expliquer le fonctionnement. On s'aperçoit dans ce cas que ce n'est pas utile que pour les autres.

Sinon, j'ai pour habitude de déclarer des variables contenant majuscules et minuscules du style "MaVariable". Comme je tape tout en minuscule lorsque je saisi le code, si, pour citer l'exemple de Tan, je tape "mavariabe", je m'aperçois tout de suite grace à l'écriture intuitive de vb que j'ai fais une faute de frappe.

moq

[Papy Turbo]

Je me permets de tagger ce thread comme [Article].

La 1ère raison est : pour qu'on ne l'efface pas.

Tous les conseils qui y sont résument super bien tout ce qu'on fait, parfois sans trop le savoir, pour écrire du code propre, pour déboguer une 'vieille appli', etc.

Et puis, quand on aura à peu près fait le tour de la question, faudra en faire un cours, un article, en tout cas quelque chose de plus que de simples conseils ou astuces.

Allez, d'autres encore, siouplait. On n'a pas fini le tour de la question : faut débattre des conventions de nommage (y a du pour, y a du contre quand c'est bêtement systématique...), par exemple, du choix de langage aussi (français/anglais essentiellement) et de la cacophonie que ça peut donner...

[Bibicmoi]

Salut tout le monde,
Papy Turbo, va falloir t'expliquer, parce que je ne comprends pas bien pour le choix du langage. Perso, je suis en français tout le temps (et c'est pas parce que je suis une quiche en anglais!! )
Par contre, pour les conventions de nommage, je dois avouer que j'ai découvert ça il n'y a pas si longtemps et qu'il était donc un peu trop tard pour moi.
Mais je pense que si je devais refaire tout depuis le début (et vous pouvez toujours courir!!) je ferai bien attention à utiliser des formes telles que "tbl_" ou "frm_". C'est beaucoup plus clair pour qui veut lire la base, ou même pour moi si j'y reviens 15 ans après : pas besoin de tout revoir pour savoir à quoi correspond tel nom. En plus, comme ça, il est possible d'appeler une table et une requête avec le même nom, ce qui n'est pas possible si on n'utilise pas les préfixes.
Mais ça, ce sont des arguments qui ont déjà dû être employés pour justifier l'utilisation de ces préfixes.
Par contre, au niveau des variables, ou même des noms de contrôles, je dois avouer que j'ai fait de grosses erreurs à ce niveau et c'est pour ça que je me permets d'écrire à nouveau.
Surtout mettez des noms explicites!!!
Je sais, c'est con à dire, mais y a vraiment des moments (surtout moi d'ailleurs) où on a la flemme de chercher un nom pour un pauvre bouton ou pour un label (surtout pour les labels) et on se dit que finalement, on peut bien laisser Bouton33 comme nom, c'est pas si mal. Eh ben non! Grossière erreur qui peut être lourde de conséquences (c'est un peu exagéré, mais c'est vrai que par moment...).
Enfin, vous avez tous dû passer par là et comprendre très bien ce que je veux dire!

Bon, je me rends compte que je suis un peu sorti du contexte initial (après tout, quel rapport avec "comment retrouver un problème"?), mais je pense qu'il fallait le rappeler encore une petite fois, surtout si Shoryu en fait un cours (eh ouais, fallait pas poser des questions à la con comme ça!! ).
Ciao.

[wytyggo]

Tous ces conseils sont vraiment bien, j'en rajouterais quelques uns :

1. En premier lieu écrire son raisonnement sur papier (type raisonnement graphcet), cela aide beaucoup surtout lorsque le code est long et complexe.

2. Bien respecter la syntaxe

Code :

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

1
2
3
4
5
If Code.Text = 1 then
    ...
Else
    ...
End If

On voit rapidement les erreurs (boucle non terminées)

3. Dès que l'on ouvre une boucle il faut la fermer tout de suite vant d'écrire le code à l'intérieur (ca limite aussi pas mal d'oublis)

4. Développer les fonctionnalités dans des procédures indépendantes : on gagne du temps pour trouver le morceau de code à débogger, et on peut réutiliser les procédures plusieurs fois. (gain de code et de temps).

5. En dernier point j'utilise très souvent les points d'arrêts de code, pour vérifier que toutes les lignes sont bien lues.

[Shoryu]

Merci à tous d'avoir répondu
depuis peu j'utilise comme la plupart d'entre vous une méthode de pas a pas en m'aidant d'un petit papier sur lequel je note l'organisation de la bdd ainsi que les différents scénarios possibles.
Aussi je fais souvent des recherches sur tout le projet en cours pour retrouver toutes les actions faites sur tel ou tel objet.
Sinon je fais toujours des sauvegardes que je laisse de coté quand ca fonctionne, comme ca si jamais ca bug, je vois le probleme en fonction de ce que j'ai modifié.
Mes noms d'objet et de variable sont tous en miniscules et séparés par des _ , ce qui evite les problemes avec les -
sinon pour le reste je fais a peu pres comme ca a été dit precedemment.
encore merci car grace a vous je passe deja moins de temps pour retrouver mes problemes

sinon ce serait bien de faire un sticky pour ce post, etant donné qu'on doit chercher le sujet dans les pages précedentes a chaque fois qu'on veut y jeter un coup d'oeil...

merci encore ^^

[romainw]

Je suis encore étudiant mais j'ai eu l'occasion (la chance) de faire des stages assez techniques par rapport à d'autres étudiants de mon école, des stages où certaines parties se déroulaient un peu dans le genre : "débug moi cette appli sur laquelle 1000 stagiaires sont déjà passés"...

Les impressions que j'ai sont :


* Trop de commentaires tue le code ! Un code bien propre utilisant des noms de variables normalisés est largement plus compréhensible.


* beaucoup de développeurs n'ont pas le réflexe "F1", "MSDN" ou recherche sur le site par exemple. On apprend plus quand on est confronté à un problème et qu'on trouve soit même la solution après quelques recherches...


* beaucoup de développeurs ne connaissent pas bien le déboggueur VB.

- Les points d'arret.
- F8 pour pas-à-pas.
- SHIFT+F8 pour executer une sub ou function directement.
- SHIFT+F2 sur une sub ou function pour accéder à son code.
- F5 pour continuer l'execution jusqu'au prochain point d'arret.
- La fenetre d'execution, qui permet d'afficher les valeurs de toutes les variables par "? NomVariable"
Les MsgBox sont une solution mais s'avèrent souvent pénibles à l'utilisation au débuggage (boucles....)


* Voici le schéma type d'une sub ou function, qui semble le plus logique à maintenir

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
Private Function ma_function() As Boolean
    Dim ....
 
    On Error GoTo Erreur
 
    'Traitements
 
    ma_fonction = true
 
Exit:
    Set iTableDef = Nothing
    Set dbs = Nothing
    Exit Function
 
Erreur:
    'interceptions d'erreurs et traitements
    MsgBox Err.DESCRIPTION
    ma_fonction = false
    GoTo Exit
 
End Function

La rédaction d'un article est une très bonne idée, à mettre en page d'accueil du forum ça éviterait surement les posts "à la va vite"

bonne continuation à tous !

[Papy Turbo]

Ouf ! des réponses, encore des réponses !!!
Voilà un sujet qui roule.

Papy Turbo, va falloir t'expliquer, parce que je ne comprends pas bien pour le choix du langage. Perso, je suis en français tout le temps (et c'est pas parce que je suis une quiche en anglais!! )

Je m'explique : nous avons la chance (ou la malchance) de
- parler français entre nous (la plupart du temps, quand on est encore lucides),
- programmer en anglais, au moins pour le VBA.
Inconvénient :
- ça donne souvent une cacophonie difficile à suivre, quand on mélange sans faire attention les deux langues, pour les noms de contrôles et autres objets (formulaires...), de variables, constantes...
- ça permet quelque chose que les US/british ne peuvent pas faire. Exemple :
++ tous les noms d'objets (tables, formulaires, contrôles...) et de procédures (Sub/Function/Properties) en anglais,
++ tous les noms de variables en français.
ou, tout simplement,
++ tout ce qui n'est pas du VBA, en français.
C'est un détail, mais ça permet d'éviter d'utiliser des mots réservés du langage comme noms de variable, procédure ou d'objets, et ça nous donne un choix plus vaste qu'aux anglais mono-linguistes.
Je dirais que la seule règle importante est : soyons cohérent, comme pour l'orthographe anglaise : soit british (synchronise avec un 's'), soit US (synchronize avec un 'z'), mais ne jamais mélanger les 2 orthographes !.

Conventions de nommage :
Je ne suis pas trop les conventions classiques, peut être parce que j'aime pas faire comme tout le monde ?
Voilà quelques suggestions personnelle, concernant les tables, formulaires et autres objets de la fenêtre base de données :
Dès qu'il y en a un certain nombre, ils s'affichent dans un ordre absurde du fait du tri alphabétique . Donc,
- chaque nom de table commence par un nombre à 4 ou 5 chiffres (00100_Clients, par exemple),
- l'ordre des chiffres respecte, autant que possible, l'ordre dans lequel les tables se 'suivent' du fait des relations d'intégrité référentielle. Exemple, un client a des factures (relation d'intég. réf. sur le [CodeClient]), donc 00200_Factures vient après 00100_Clients...
Ceci est un vaste sujet que j'aimerais bien traiter une autre fois, mais pas ce soir...
- les numéros sont assez espacés pour pouvoir insérer de nouvelles tables à tout moment sans avoir à tout renommer (sauf, pour le plaisir de "nettoyer", une fois tous les ... )
- ils permettent d'afficher les objets dans un ordre logique beaucoup plus facile à utiliser que l'ordre alphabétique.
À partir de là,
- le formulaire "Clients" peut s'appeler 00100_Clients. Ça ne pose aucun problème, et je n'ai jamais ressenti aucune confusion entre un formulaire et une table...
Par contre, tu as raison, il peut y avoir conflit entre requête et table, donc
- toutes les requêtes portent le nom du formulaire (ou de l'état) dont ils sont la source, précédé d'un 'F_' pour formulaire, d'un 'E_' pour un État. Exemple :
++ requête F_00100_Clients est la source du formulaire 00100_Clients,
++ requête F_00200_Factures est la source du formulaire 00200_Factures...
Lorsque la requête est la source d'une liste déroulante ou autre contrôle de formulaire ou d'état, j'ajoute le nom du contrôle :
++ requête F_00100_Clients_ChoixTypeClient est assez explicite pour qu'on ne puisse pas se tromper.
- Quant une requête est utilisée dans le code, elle porte le nom du formulaire + un 'x' (pour eXécution) + un n° (pour l'ordre d'exécution) + une description. Exemple : requête F_00100_Clients_x001_CompteFacturesImpayées
Si elle est appelée depuis un module, pareil, sauf le nom du Module en tête. Exemple : requête M_00800_Analytique_x001_SupprimeAnciennesEcritures est appelée depuis le Module 00800_Analytique.
etc.
Ce qui implique qu'aucune requête n'est jamais, absolument jamais jamais jamais, utilisée plus d'une fois. Si besoin, faire copie sous un autre nom.

Pour les noms de contrôles, j'aime bien les conventions classiques :
- cmdNomDuBouton pour les 'COMmand buttons'. Dans certains projets, ce sera 'butNomDuBouton' pour BUTton...
- lst... pur les liste,
- lbl pour les étiquettes,
- etc.
sauf : txt... pour les 'text boxes' qui, honnêtement, me gonfle. J'ai honte, peut être je devrais faire un effort, mais je ne mets jamais de préfixe aux 'zones de texte'.

Par contre, dans le code VBA, pour les distinguer des variables, j'encadre systématiquement les contrôles et les noms de champs avec des crochets carrés :
- [TypeClient] est un contrôle,
- rsClients![TypeClient] est un champ,
- TypeClient est une variable.

Pour les variables : très simple :
- toujours explicites bien sûr et toujours 'As TypeVariable' (finis les suffixes $ % #)
- gNomDeVariable pour les variables Globales. Ce qui me permet de me mettre en rogne ensuite, parce que j'aime pas les variables globales (Vaut mieux une bonne classe bien propre !), mais ça nous entraîne trop loin...
- mNomDeVariable pour les variables au niveau du Module.
- rsNomDuRecordset pour les recordsets.
C'est à peu près tout.
Les préfixes du type strNomDeVariable pour les strings (trop sexy pour mon âge ?) ou pire : vNomDeVariable pour les Variants me gonflent.
Si j'ai un doute sur le type de la variable, j'appuie sur Maj+F2, puis retour à la ligne de code avec Ctrl+Maj+F2.
Mais c'est surtout parce que je ne supporte pas les Variant ! Faut un flingue sur la tempe pour en utiliser une

Bon, y se fait tard, romainw, faudra qu'on reparle de ta 'fonction type' qui retourne Faux en cas d'erreur...

[wytyggo]

Quel sera le courageux pour faire la synthèse avec des paragraphes et tout, et tout... pour tous les jeunes padawans de la programmation.

Le tout c'est de trouver Yoda.

PS : c'est trop tard pour faire cet exercice

et je suis trop flemmard

[Papy Turbo]

T'inquiètes. Ça sera fait. Quand ? quand y aura le temps. Comment ? comme ça viendra.
L'intéressant, c'est déjà d'aborder les divers points et techniques et de voir les différences de points de vue.
Même le jour où y aura un résumé, une vue d'ensemble ou autre, il y aura toujours lieu de débattre...

et je suis trop flemmard

T'as bien raison, mais qu'est-ce que tu fais là au lieu d'être sous un cocotier ?

[NiKro75]

Ah, mon message a disparu lors du pb technique...

Je voulais juste signaler que pour débugger, simplement laisser le pointeur de la souris sur le nom des variables et des fonctions permet de connaitre leur valeur en 'Infos bulles'.
C'est pratique, ca permet de se passer de pas mal de 'Debug.Print', en combinaison avec les points d'arrêts, voire meme des fenêtres Exécution et Variables Locales dans certains cas, ça rend l'affichage moins fouillis .
C'est un truc bête mais j'ai mis du temps avant de m'en rendre compte...

[Bibicmoi]

Bon, j'avais pondu un sacré message pour répondre à Papy Turbo, mais il a été effacé et j'ai pas le courage de recommencer.
Par contre, y a un post qui vient d'arriver et où on pose la question de savoir

Doit on déclarer ses variables au début de chaque fonction ou alors on peut les déclarer juste avant d'en avoir besoin en plein milieu de la fonction.

Voila donc ce que j'ai répondu :

Pour répondre à ta question, personnellement, je les déclarerais toutes au début (j'y mets au conditionnel, parce que je ne déclare rien du tout, c'est encore mieux... Si Papy Turbo me lisait, je crois que je me ferais lyncher!!!).
C'est plus clair, toutes tes variables sont en un seul et même endroit, comme ça, si tu veux la retrouver pour savoir si tu l'as bien écrit correctement, si tu as mis le bon type et tout..., tu vas tout de suite voir au début de ton programme.
Si tu t'amuses à déclarer en cours de route, tu vas jamais t'y retrouver. Parce que pour savoir où c'est la première fois que tu l'emploies....!! Tu peux t'amuser!!
Un autre truc aussi, c'est assez contraignant quand t'en as 15000, mais bon, c'est assez rare quand même!, classe-les par ordre alphabétique. Tu les retrouvera encore plus facilement.

A mon avis, c'était bien de le rappeler ici, donc voila!
Ciao.

[Maxence HUBICHE]

* Trop de commentaires tue le code ! Un code bien propre utilisant des noms de variables normalisés est largement plus compréhensible.

Je ne partage pas ce point de vue :
Oui, la normalisation est essentielle.
Oui les commentaires sont essentiels.
Il sera beaucoup plus rapide d'avoir des indications sur ce qui se passe dans une procédure que de chercher à comprendre ce sui se fait en allant déchiffrer le contenu, la logique de telles requêtes appelées dans telle procédure quand même !

* Voici le schéma type d'une sub ou function, qui semble le plus logique à maintenir

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
Private Function ma_function() As Boolean
    Dim ....
 
    On Error GoTo Erreur
 
    'Traitements
 
    ma_fonction = true
 
Exit:
    Set iTableDef = Nothing
    Set dbs = Nothing
    Exit Function
 
Erreur:
    'interceptions d'erreurs et traitements
    MsgBox Err.DESCRIPTION
    ma_fonction = false
    Goto Exit
 
End Function

Je partage l'avis de Romain à ce sujet !
TOUTES LES PROCEDURES devraient être sur ce modèle général.
Cependant, je ferai 2 petites modifications :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
Private Function ma_function() As Boolean
    Dim ....
 
    On Error GoTo Erreur
 
    'Traitements
 
    ma_fonction = true
 
Exit:
    On error Resume Next
    Set iTableDef = Nothing
    Set dbs = Nothing
    Exit Function
 
Erreur:
    'interceptions d'erreurs et traitements
    MsgBox Err.DESCRIPTION
    ma_fonction = false
    Resume Exit
 
End Function

L'Exit étant la partie systématique, seuls les fermetures et nettoyages y sont indiqués. Une erreur dans la fermeture d'un objet OLE non ouvert n'est pas à prendre en compte, par exemple. On veut le fermer, il l'est déjà, on s'en fout de retourner dans le gestionnaire d'erreurs ! (enfin... c'est mon avis.
Il est préférable d'utiliser Resume en lieu et place de Goto, car Resume est sensé faire un Err.Clear, que ne fait pas le Goto.

Sinon, tout le reste est des plus intéressants, et j'ai l'impression, à priori, que tout a été dit.