Discussion :

[Papy Turbo]

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.

Flemmard ! Aucune excuse.
À propos des déclarations de variables,

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

T'as gagné.
Option Explicit est un must absolu. On n'est pas là pour faire du vbScript, et la meilleure façon de comprendre à quoi servent les déclarations de variables, c'est précisément d'aller passer un mois (ou + !) sur quelques milliers de lignes en vbScript ! Tu comprendras ta douleur et tu ne te poseras plus jamais la question.

Sinon, d'accord de faire au + simple : toutes les variables locales en tête de procédure. L'ordre alphabétique ??? Bof, je sais pas si ça aide. Comme indiqué + haut, pour savoir le type et la portée d'une variable, Maj+F2 pour y aller, Maj+Ctrl+F2 pour revenir sur la ligne de code, c'est pas sorcier...

Ah, j'en profite pour ajouter :
- sauf cas forcé, mais très rare, je ne déclare jamais aucune variable '... As Variant', ni '... As Object'
- ... As Variant : laisse passer des erreurs de compilation ou de runtime très difficiles à détecter lorsqu'on attend un certain type de données et qu'on en obtient un autre. Surtout du fait que VBA convertit systématiquement les données d'un type en un autre. Donc, même si un paramètre de procédure doit être Variant, par exemple parcequ'il peut être Null ou String, je vérifie toujours le type de Variant. Exemple, dans le module de classe 'Bonhomme' :

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
Option Compare Database
Option Explicit
 
Dim mNomFamille As Variant
 
Public Property Get NomFamille() As Variant
    NomFamille = mNomFamille
End Property
Public Property Let NomFamille(ByVal NewNomFamille As Variant)
    If Not IsNull(NewNomFamille) Then
        If VarType(NewNomFamille) <> vbString Then
            Err.Raise vbObjectError + flerrTypeIncompatible, _
                      "Let NomFamille", "Le nom de famille doit être une chaîne de caractères."
            '=========================================
        End If
    End If
    mNomFamille = NewNomFamille
End Property

- ... As Object : sauf cas impossible ou DLL non typée, dont la doc dit spécifiquement "Vous devez déclarer vos variables 'As Object'". Ce qui n'est pas bon signe quant à l'utilisation d'une telle DLL...
Je dirais même plus : non seulement déclarer chaque objet '... As ObjetSpécifique', mais toujours indiquer la librairie qui contient l'objet. Exemple :

Code :

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

1
2
3
4
5
6
7
8
Dim rsBonshommes As DAO.Recordset
'ou bien, selon le choix de méthode
Dim rsBonshommes As ADODB.Recordset
'mai jamais, au grand jamais :
Dim rsBonshommes As Recordset
'De même :
Dim Classeur As Excel.Workbook
Dim Feuill1 As Excel.Spreadsheet

etc.
Ça évite pas mal de confusions, surtout bien sûr, lorsqu'on travaille à plusieurs. Il y a beaucoup plus de possibilités d'erreurs qu'on ne pense : Outlook.AddressEntry ou CDO.AddressEntry ? Donc, soyons aussi précis que possible !

[Papy Turbo]

Aïe aïe aïe, on dérape vers le débat sur les contrôles d'erreur, avec chacun sa petite routine type !!!
Donc, voici ma mienne, qui réutilise volontairement des termes extraits de .Net. J'aime particulièrement le 'Finally' qui décrit bien son rôle, déjà exposé par Maxence : faire une sortie de procédure propre, qu'il y ait eu une erreur ou pas.

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
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
'TOUJOURS Public ou Private, histoire d'être sûr au 1er coup d'oeil
Public Function SubTemplate() As CeQuElleDoitRenvoyer
Dim ... As Librairie.Objet
Const ...
 
    On Error GoTo Catch
    '... code de procédure
    'ici on attend un erreur spécifique
    On Error GoTo XxxError
    '... code qui peut provoquer l'erreur spécifique n° Yy
    On Error GoTo Catch 'retour à 'gestion d'erreur générale'
    '... suite du code
Finally:
    On Error Resume Next
    'Fermetures : d'Excel ou autre objet Automation, formulaire, état...
    ChaqueObjet = Nothing
    Exit Function '=================================
XxxError:
    'en commentaire : N° et Description de l'erreur ATTENDUE
    If Err = Yy Then
        Resume Next 'ou autre traitement d'erreur
    End If
    'noter que si le code d'erreur est autre que celui attendu, 
    '    on 'tombe' dans la gestion d'erreur par défaut, 
    '    ci-dessous, éventuellement avec un 
    Goto Catch
ZzzError:
    'autres erreurs spécifiques à traiter cas par cas...
    If Err = Zz Then 
         ...
         Resume Next
    End If
Catch:  'ici traitement des erreurs NON PRÉVUES
    Select Case MsgBox(Err.Description, vbAbortRetryIgnore + _
                      vbExclamation, flApp.Title)
    Case vbAbort
        Resume Finally
    Case vbRetry
        Resume
    Case vbIgnore
        Resume Next
    End Select
End Function

Voir un exemple concret de traitement d'erreur spécifique, ici (voir le 'On Error Goto errOuvrirExcel') : http://www.developpez.net/forums/vie...165909#1165909
Le 'On Error Resume Next', juste après Finally, a été expliqué par Maxence, je suis bien d'accord.

Par contre, j'ai essayé, il y a quelques années, de typer toutes les fonctions comme booléennes, renvoyant 'Faux' en cas d'erreur, 'Vrai' si pas d'erreur (ou l'inverse).
J'ai aussi essayé, comme les APIs de Windows et autres fonctions C, C++ courantes, de typer les fonctions comme Long, et leur faire renvoyer :
- 0 si pas d'erreur,
- sinon, le code d'erreur. Ce qui est déjà plus précis.
J'en suis revenu :
- c'est très lourd,
- on n'est pas en C++,
- on perd la simplicité des affectations directes de fonctions

Code :

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

    Set rsBonhommes = BDD.GetRecordsetBonshommes(NomBonhomme As String)

- on ne peut plus appeler de Sub (ni de fonctions en ignorant la valeur de retour),
- ça oblige à faire des tests en plus, pour voir si y a erreur,
- on finit par se mélanger les pinceaux avec la question de savoir qui (à quel niveau) doit afficher le message d'erreur à l'utilisateur ??? (la routine 'système', au fin fond de sa librairie ? ou l'objet métier ?? ou pire : l'objet d'accès aux données, appelé par l'objet métier ? ou, tout en haut, la routine évènementielle du formulaire qui a déclenché tout ça ?)
- etc.
Bref, impossible de faire un cours complet sur le traitement d'erreurs ici, mais, à mon avis qui n'engage que moi et en quelques lignes, voilà ma tactique préférée :
- la fonction type telle que l'exemple ci-dessus, de même que toutes Subs, évènements, etc., avec un traitement d'erreur complet (au lieu de MsgBox, un 'Error Handler' affiche le message et écrit dans un journal qui sera envoyé par mail au service technique, si y a, ou à moi, comme programmeur !) s'applique systématiquement au niveau 1 de l'interface utilisateur.
C'est à dire dans tous les évènements des formulaires, états + routine de démarrage (la fameuse Sub Main() de VB)et de clôture de l'application, s'il y en a.
Par contre, et notamment en ce qui concerne les objets métier, pratiquement aucun contrôle d'erreur. Ça va faire plaisir aux flemmards, mais en fait, y a du boulot pour lever des erreurs (Err.Raise ...) ou de surclassement.
Voir un exemple type de propriété d'objet métier (classe 'Bonhomme') qui lève une erreur, dans mon message précédent un peu plus haut.
Exemple de Surclassement :
- une sub/fonction est appelée depuis l'interface (BoutonCompact_Click, par exemple) pour compacter la base de données contenant les tables,
- d'autres utilisateurs sont encore connectés,
- la sub chope une erreur de type 'Impossible d'ouvrir la base en mode Exclusif', ce qui n'est pas très parlant pour les utilisateurs,
- elle lève une erreur (Err.Raise ...) avec un message plus précis, du type "Impossible de compacter la base tant que d'autres utilisateurs sont connectés..."
- l'erreur est captée (voir Function Template ci-dessus) par l'évènement click du bouton qui affiche ce message en proposant les 3 choix de base, ou autres choix spécifiques à cette erreur là (c'est toi le programmeur !).

De même que les objets métier, les bibliothèques de code, réutilisables d'une application à l'autre, n'affichent jamais un message d'erreur : elles provoquent ou reclassent les erreurs et laissent l'interface de l'application 'parler' avec l'utilisateur.
Énorme avantage lorsque vous utilisez ces bibliothèques dans une application de type 'Service Windows' ou fonctionnant sur un serveur, donc sans aucun utilisateur devant l'écran : mode 'silencieux'.
Mais aussi : considérez que vos routines (métier, bibliothèques, etc.), appelées depuis l'interface utilisateur, se comportent exactement comme une extension du langage VBA. Traitez vos propres subs et fonctions comme si c'étaient des mots clés du langage, et tout devient plus simple (enfin, ça, c'est moi qui le dit ).

[Duguesclin]

J'ai aussi essayé, comme les APIs de Windows et autres fonctions C, C++ courantes, de typer les fonctions comme Long, et leur faire renvoyer :
- 0 si pas d'erreur,
- sinon, le code d'erreur. Ce qui est déjà plus précis.
J'en suis revenu :
- c'est très lourd,
- on n'est pas en C++,

Juste en passant, C++ ne gère pas les erreurs de cette façon mais avec les Exceptions

[Duguesclin]

Vu que c'est un débat, je me permet d'ajouter mon grain de sel !

Le traitement des erreurs de papyturbo est intéressant, mais je n'aime pas les multiples on error goto...
Et il est possible de les éviter, cela rend le code plus clair:

Code :

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

1
2
3
 
On Error GoTo Catch
    '... code de procédure

Et si une erreur spécifique apparait ici, qui doit être traité par XxxError, elle atterit dans Catch !

Code :

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

1
2
3
4
5
6
 
    'ici on attend un erreur spécifique
    On Error GoTo XxxError
    '... code qui peut provoquer l'erreur spécifique n° Yy
    On Error GoTo Catch 'retour à 'gestion d'erreur générale'
    '... suite du code

A mon avis il serait interessant d'écrire quelques modifications:
( je ne poste pas le code en entier, juste les modifications)
D 'abord un seul on error goto !

Code :

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

1
2
3
4
5
6
 
On Error GoTo XxxError ' Début de traitement des erreurs
    '... code de procédure
    'ici on attend un erreur spécifique
    '... code qui peut provoquer l'erreur spécifique n° Yy
    '... suite du code

ensuite plutôt qu'une sucession de If then .. Endif : un Select Case

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
 
XxxErrr:
    Select Case Err ' voire Err.Number
    Case Xxx
        'traitement erreur Xxx
    Case Yyy
        ' traitement erreyr Yxx
    Case Else
        ' cas général  remplacemennt de  Catch
       'ici traitement des erreurs NON PRÉVUES
            Select Case MsgBox(Err.Description, vbAbortRetryIgnore + vbExclamation, flApp.Title)
            Case vbAbort
                    Resume Finally
            Case vbRetry
                    Resume
            Case vbIgnore
                    Resume Next
            End Select
    End Select

l 'avantage est un code plus lisible et toutes les erreurs sont traitées.

Pour ma part je pense qu'on ne peut pas se contenter d'un seul type de gestion d'erreur.
Et il vaut mieux avoir plusieurs cordes à son arc, plutôt que de passer à côté de solutions simples.
Par exemple: Pour un fonction simple, que l'on va appeller dans une autre fonction ou procédure, on l'on a besoin de savoir uniquement si elle a réussi ou pas.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
' par exemple écriture d'un log
Function SimpleLog() As Boolean
On Error GoTo exit_SimpleLog
    ' instructions à exécuter
    ' exemple traitement ecriture du log
    SimpleLog = True
    Exit Function
 
exit_SimpleLog:
    On Error Resume Next
    SimpleLog = False
End Function

Au final on veut gerer une situation avec un log écrit ou pas.
On a pas besoin de gérer toutes les erreurs qui peuvent se produirent dans la fonction simple (disque plein, n° de fichier invalide etc..).
Effectivement dans ce cas si on appelle Simple sans tester la valeur de retour, elle peut échouer sans avertissements et les erreurs ne seront pas traitées!
Remarque: on peut détailler davantage la gestion d'erreur dans la fonction si c'est justifié.
A utiliser avec discernement
( notament comme l'a fait remarqué papyturbo pour les affectations directes de fonctions)

Ensuite pour traiter les erreurs:
D 'abord créer un code d'erreur spécifique en tête de module:

Code :

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

1
2
 
Public Const Err_SimpleLog = vbObjectError + 513 ' erreur retourné par la fonction simple

Puis intégrer la gestion d'erreur de Simple dans une autre fonction:

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
23
24
 
Function Principale()
On Error GoTo err_Principale
'  traitement de principale
 
' appelle de simple , provoque une erreur en cas d'échec
If Not (SimpleLog) Then Err.Raise (Err_SimpleLog)
' SimpleLog a réussi
 
exit_Principale:
    On Error Resume Next
     ' nettoyage et sortie
    Exit Function
 
err_Principale:
    Select Case Err.Number
    Case Err_SimpleLog
        ' traitement approprié en cas d'erreur de simple
        ' exemple: msgbox "Le log n'est pas écrit",vbinformation,"Avertissement'
    Case Else
        'autres cas
    End Select
    Resume exit_Principale  ' dans tous les cas  on arrive ici si l'erreur est traitée correctement
End Function

[stigma]

Ce post est vraiment très interressant. Je suis d'accord avec les règles de nommage de Papy Turbo, nénanmoins je ne resiste pas au plaisir d'ajouter ma pierre au sujet des noms de champs.
Ce conseil m'a été donné par mon chef de service et je ne regrette pas de l'utiliser systématiquement, son utilité est flagrante dans le cas de bases comportant un grand nombre de tables.

exemple :

Nom de la table : Stocks

Nom des champs : Stock_Date, Stock_Quantite, Stock_Controle etc....

J'ajoute donc un 's' au nom de la table, tandis que le nom du champ reprend le nom de la table sans le 's' avec _xxxxx

Lors de requêtes SQL complexes, on repère tout de suite à quelle table le champ appartient.

PS: Mais le nom '00100_Clients', c'est bien trouvé aussi !

[Papy Turbo]

Duguesclin :
Je ne vais pas re-citer tout ton message.
En gros, pas d'accord :
1- concernant le regroupement de toutes les erreurs prévues, pour l'ensemble d'une procédure, sans mettre

Code :

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

1
2
3
4
5
'ici on attend un erreur spécifique 
    On Error GoTo XxxError 
    '... code qui peut provoquer l'erreur spécifique n° Yy 
    On Error GoTo Catch 'retour à 'gestion d'erreur générale' 
    '... suite du code

à chaque erreur attendue, c'est sûr que j'apprécie les simplifications, mais pas celle là. Je faisais comme toi il ya quelques années, et c'est l'exemple de la gestion d'exception qui m'a ouvert les yeux sur le besoin d'être plus précis.
- si une erreur est attendue sur une ligne de code donnée, elle ne l'est que sur cette ligne là.
- si la même erreur, ce qui arrive en particulier pour toutes les erreurs génériques (mauvais type de données, affectation de Null à une variable non variant, objet non défini, etc.) se produit sur une autre ligne de la même procédure,
--- tu ne sauras jamais qu'elle a eu lieu, parce que ton code 'la traite' sans que tu le saches...
--- il n'y a aucune raison a priori de la traiter de la même manière que la 1ère fois. Peut être que tu choisiras le même traitement (dans ce cas là, il y aura 2 fois le même "On Error Goto XxxError"); peut être pas ; mais tu dois choisir en connaissance de cause.

2- Un fonction qui ne renvoie que Vrai ou Faux, tu te doutes que j'en ai, comme tout le monde, mais une fonction qui filtre les erreurs sans les signaler, avec un :

Code :

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

1
2
3
4
exit_SimpleLog: 
    On Error Resume Next 
    SimpleLog = False 
End Function

là, excuse moi, mais, si tu bossais dans mon équipe, tu serais viré (ce qui, dans le jargon local, veux dire : tu payes un pot à toute l'équipe, mais aussi, tu supprimes ce 'On Error Resume Next' pour qu'on capture l'erreur).
En clair, jamais aucune erreur non prévue n'est passée à la trappe sans être répertoriée, avoir une réponse spécifique, etc.

Pour moi, c'est toute la différence entre une application fiable et un (très bon, pourquoi pas ?) bidouillage. Je n'aime pas qu'on soulève le tapis pour planquer les erreurs non prévues. On les traite toutes.

J'en profite pour, quand même, être d'accord avec toi sur un point :
On peut et on doit éviter la prolifération des 'On Error Goto...', en les utilisant le moins possible.
Je m'explique :
- lors de la création d'une nouvelle application, je préfère commencer sans aucun code de gestion d'erreur. Une application qui tourne correctement comme cela est une base très solide et facile à faire évoluer. Dans le meilleur des cas, le code d'erreur sera ajouté au dernier moment, juste avant la livraison au client (départ de la phase bêta).
- à chaque fois que les tests préliminaires signalent 'une erreur', j'essaye de la gérer par code, sans aucun 'On Error Goto...',
Exemple : erreur 'Fichier non trouvé' pendant une opération FileCopy...
Ligne de code d'origine :

Code :

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

    FileCopy OldPathName & FileName, NewPathName & FileName

Lignes de code corrigées, pour traiter l'erreur :

Code :

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

1
2
3
4
5
    'Si le fichier existe dans l'ancien dossier
    If Dir(OldPathName & FileName) > "" Then
        'Copie dans le nouveau dossier
        FileCopy OldPathName & FileName, NewPathName & FileName
    EndIf

Ça n'est qu'un exemple, mais la quasi totalité des erreurs peuvent être traitées comme cela, et c'est 100(000) fois préférable : code plus compact et lisible parce qu'on n'a effectivement pas besoin d'aller voir plus bas ce qui se passe en cas d'erreur, généralement plus rapide, ...

stigma : d'autant plus d'accord avec toi, que c'est à peu près systématiquement ce que je fais pour les champs. À une virgule près, je ne suis pas fan des "_" et je préfère la notation dite polonaise, plus compacte :
Nom de la table : 00250_Stocks

Nom des champs : StockDate, StockQuantite, StockControle, etc...

La précision du 's' sur le nom de table est bien aussi : souvent, on trouve n'importe quoi, la moitié des tables au singulier, l'autre moitié au pluriel

[olivier]]

Juste une bricole pour revenir sur le sujet initial "Debugger son code".
Rédiger son code en respectant l'indentation simplifie grandement la vérification des boucles, des if/then/else et autres imbrications.

Olivier

[stigma]

Tu as raison Olivier, l'indentation est importante. J'ai vu trop de code sans aucune indentation ni inter-ligne et c'est drôlement coton à analyser !!
Il faut aérer le code et pas hésiter à mettre des lignes vides pour séparer les différents modules.

[Papy Turbo]

Puisqu'on parle d'indentation, j'en profite pour signaler un outil qui n'est pas parfait, mais absolument remarquable : mztools, disponible gratuitement sur www.mztools.com
Il existe en versions :
- VBA (que je n'ai pas encore testée !)
- Visual Basic 5.0,
- VB 6.0 : que j'ai testé et qui m'a fait gagner beaucoup beaucoup de temps.

Il permet beaucoup de choses, y compris mettre au propre, en un clic, l'indentation du code ! Mais surtout :
- insertion du code d'erreur
- multiples modèles de code,
- les modèles de code peuvent inclure les variables les + utiles : nom du module, nom de la procédure, etc; mais aussi des variables personnelles !
- détection de variables ou de routines non utilisées,
- etc. etc. etc.

UN DOIT ABSOLU, pour ne pas dire un MUST !

[DonFelipe]

Bonjour ... voila, ce post n'est pas vraiment une question technique .... 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 ne réponderais qu'une seule chose : ma signature parle d'elle même
C'est en effet sur le trucs les plus bêtes que l'on passe le plus souvent le plus de temps...
Sinon pour répondre quand même à la question initiale, je passe le plus souvent par l'exécution pas-à-pas et aussi par un grand nombre de MsgBox qui m'affichent les valeurs, paramétres, etc, etc....

[nno]

Salut a tous
Bref on n'est pas sortit de l'auberge.
Une bonne dose de patience et beaucoup de rigeur.
pour Papy Turbo j'ai essayer le lien vers www.mztools.com il ne fonctionnent pas ?
Bonne journée

[stigma]

Chez moi ça marche !

[moq]

j'ai essayer le lien vers www.mztools.com

Dans le lien que donne Papy Turbo il y a un point au bout, il suffit simplement de l'enlever et le lien fonctionne.

moq

[Papy Turbo]

Point supprimé !

[Tofalu]

Voilà, je viens de terminer de lire (un peu en survol ce thread) (il est lon, surtout avec les monologues de l'imbatable Papy Turbo )

Ceci cit, même si Papy Turbo, m'empêche de tout lire parfaitement (il en a écrit trop), je suis en grande partie d'accord avec sa pratique et notemment la théorie de la régression sur papier.

Je pense que beaucoup ont trop tendance à se lancer trop vite dans la réalisation et l'écriture du code. Je pense que tout étude de prjet doit d'abord être fait sur papier. Pour la partie Base de données, il y a Merise. On réalise un Modèle conceptuel des données (MCD) que l'on valide. Puis on convertit le MCD en modèle relationnel à l'aide des règles de passages définies par Merise. Enfin on réalise le modèle physique sous Access.
On évite bien entendu, les espaces et les caractères spéciaux dans les noms de champs et de tables.

Au niveau du code :

Dés que le problème se corse (enchevêtrement d'itérations et de conditions, rien de tels que le papier.) Si besoin, mise en place d'un modèle conceptuel de traitement analytique pour l'interrogation successives des tables puis d'un algorithme.
Pour ce qui est des varables, on privéligira Option Explicit afin de forcer la déclaration. Moi, j'aime bien mettre une majuscule en deuxième ou troisème position comme ça, j'écrit mon code en minuscule et quand je retourne à la ligne, si ma variable est bien écrite, la majuscule apparait.
Pour le choix du langage, je privilégie l'anglais. Je préfère MyField.Text à MonChamp.Text
Pour ce qui est du nommage, je reste assez mitigé. Tout dépend du nombre de contrôle. Si les contrôles ne sont pas sollicités par du code, je laisse access géré (Texte0, Texte4, etc), sinon, c'est plutôt txt_nom.
Pour les tables, je conserve les nom du modèle conceptuel afin de rester cohérent. 00010_Personnel, cela me parle pas beaucoup. Je préfère Personnel.

Enfin pour trouver les erreurs, rien de tels que comme PapY turbo, la méthode étau accouplée au découpage du code en fonctions et procédures simples. On ajoute à ceci, un peu d'espion et msgbox et le tour est joué.

Ceci dit, si on a bien posé le problème depuis le début, il est rare que l'application ne fasse pas du tout ce que l'on attend. Et la correction se limite juste en général à un EndIf ou à une lettre dans une variable.

Voilà, j'ai apporté ma pierre à l'édifice, en espérant que je n'ai pas fais trop de faute d'ortograf'.

[Requin15]

Bonjour à tous

J'ai une question très simple :

est il possible de voir tout ce que fait une macro : écriture de champs, lecture, création de table etc...

et cela sans avoir à recourir au débug.print ?

En gros, il me faudrait un fichier de log : est ce qu'il y a une telle fonctionnalité ? si non, comment la faire ?

Merci bcp !

[Papy Turbo]

On évite bien entendu, les espaces et les caractères spéciaux dans les noms de champs et de tables.

Bien sûr, si tu continues à utiliser les mêmes bases de données qu'utilisait mon grand-père avant la guerre de 14 (je parle d'Oracle, SQL Server et similaires...), ça pose problème.
Mais avec Access, quelqu'un a déjà eu un problème ? 8)

00010_Personnel, cela me parle pas beaucoup. Je préfère Personnel.

D'accord s'il n'y a pas plus de 10 ou 20 tables.
Et même. J'utilise ça uniquement pour voir les objets par ordre logique, plutôt que par ordre alphabétique.
C'est d'abord vrai pour les requêtes :
- si elles sont groupées dans l'ordre des objets (Formulaire, contrôle de formulaire, état...) auxquels elles appartiennent, tu gagnes un temps considérable lorsque tu débarques sur une appli que tu ne connais pas. Ou la tienne, que tu n'as pas revue depuis des mois...
- même pour les tables, je serais d'accord d'utiliser n'importe quel type de regroupement logique.
Un nom de domaine ou similaire, par exemple :
- Clients_Clients
- Clients_Contacts
- Clients_Commandes
- Clients_Factures
- Clients_LignesFactures
etc. Et, plus loin,
- Fourn_Contacts
- Fourn_Commandes
- Fourn_Factures
- Fourn_Fournisseurs
- Fourn_LignesFactures
etc.
T'as vu, j'ai été jusqu'à mettre une abbréviation en 4 lettres, alors que j'ai (aaaargh !) horreur absolue des trigrammes et autres raccourcis obscurs.
Mais bon, les n°s que j'utilise sont des indexes permettant de jouer avec cet ordre logique.
Essaye une fois, je suis persuadé que tu seras convaincu (sur une appli avec au moins 50 tables et + de 1000 requêtes ).

Requin15, salut,
- si par 'macro' tu veux dire 'pas du code VBA', alors, ça m'étonnerait.
- en VBA, c'est assez facile de te faire un journal (log, in english), avec l'objet fso (file system object).
Mais, dans tous les cas, il faudra ajouter au moins une ligne de code avec la description de ce que tu veux voir dans ton journal. Ça fera autant, sinon + de code, qu'un bon vieux Debug.?

[mimielapetitesouris]

perso, je pense qu'il vaut mieux prévenir que guérir hihi !

1. toujours vérifier dans l'aide (si on en a une qui marche) que les instructions sont écrites correctement

2. OK pour utiliser des mots clés dans les objets : moi c'est T, F, R, FJ, TJ pour les tables, formulaires, requêtes, formulaire jointure, table de jointure.

les états j'ai pas encore décidé, j'en ai pas encore conçu !

j'ai repris ce conseil d'un bouquin que j'avais lu dans la série formation rapide de Dunod

3. réfléchir très longtemps à ce qu'on veut faire dans la tête, et si c'est pas clair, réfléchir encore !

4. décortiquer les gros codes en petits bouts plus digestes (plus facile pour trouver les bêtises)

5. mettre très peu de msgbox (je les utilise seulement si y a un bug sévère) et les effacer dès que le point est résolu, pour passer au suivant

6. se faire du code de référence, où on est sûr que ça marche, pour le reprendre dans les gros trucs (j'adore le copier coller ça va plus vite) faut juste penser à bien adapter la chose !

7. avoir une tablette de chocolat dans le coin héhé, ça sert toujours pour remonter le moral !

8. avoir une référence sous la main (Developpez.com, msdn, etc...) et rechercher des exemples similaires pour donner des idées et des illuminations pour trouver les erreurs

9. si ça marche pas, un point d'arrêt, ou encore le pas à pas (pas encore eu besoin de l'utiliser celuilà)

10. si vraiment, on ne voit pas la solution du bug, essayer de faire un équivalent en requête si c'est possible, ça sera toujours une façon de contourner le problème !

voilà ce que j'ai appris très vite, en débutant !

[Nohant]

Je m'explique :
- lors de la création d'une nouvelle application, je préfère commencer sans aucun code de gestion d'erreur. Une application qui tourne correctement comme cela est une base très solide et facile à faire évoluer.
- à chaque fois que les tests préliminaires signalent 'une erreur', j'essaye de la gérer par code, sans aucun 'On Error Goto...',
Exemple : erreur 'Fichier non trouvé' pendant une opération FileCopy...
Ligne de code d'origine :

Code :

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

    FileCopy OldPathName & FileName, NewPathName & FileName

Lignes de code corrigées, pour traiter l'erreur :

Code :

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

1
2
3
4
5
    'Si le fichier existe dans l'ancien dossier
    If Dir(OldPathName & FileName) > "" Then
        'Copie dans le nouveau dossier
        FileCopy OldPathName & FileName, NewPathName & FileName
    EndIf

Ça n'est qu'un exemple, mais la quasi totalité des erreurs peuvent être traitées comme cela, et c'est 100(000) fois préférable : code plus compact et lisible parce qu'on n'a effectivement pas besoin d'aller voir plus bas ce qui se passe en cas d'erreur, généralement plus rapide, ...

Salut PapyTurbo,

ben justement c'est le cas typique où je suis partagé, est-il vraiement plus performant de lancer systématiquement un controle pour vérifier que la procédure peut être lancée ou gérer le cas où l'erreur se produit ?
dans l'ex que tu donnes, je ne suis pas sûr que l'on puisse voir la différence mais dans 99% des cas la copie va se faire sans pb et le test aura été fait pour rien. Par contre c'est vrai que c'est bcp plus lisible et compréhensible.
C'est Tofalu qui a attiré mon attention sur ce fait

Je pense qu'il faut tenir compte de la fréquence d'apparition de l'erreur (pas facile sauf si déja une bonne connaissance de l'appli) et de l'impact qu'elle peut avoir.

[FRED.G]

Je pense qu'il faut tenir compte de la fréquence d'apparition de l'erreur

Je partage ce point de vue.

Ainsi je préfère généralement réserver la gestion d'erreur avec ON ERROR GOTO seulement à ce qui apparaît comme exception (c'est à dire ce qui n'apparaît pas fréquement).
Pour le reste effectivement, mieux vaut prévenir que guérir et donc coder en amont de façon à carrement éviter que l'erreur ne puisse apparaître.

Mais pour moi, et à la différence de Papy Turbo, il y a (presque) commune mesure entre "prévention en amont" et "gestion en aval".

C'est pourquoi lorsque j'ai le choix, j'essaie de confronter les deux stratégies en donnant certes la priorité à la prévention des erreurs, mais cette priorité n'est pas absolue.