Discussion :

[Serge57]

Bonjour Etienne,

Me revoilà pour la suite du cours …

Donc, dès que tu as fait ton nettoyage (étape 1), avec quelques tests pour que ça compile et que ça marche quand même, tu le mets en pièce jointe et on revoit ça.

Ce n’est pas un nettoyage que j’ai fait, mais j’ai mis tous les « ON ERROR GOTO CATCH » en commentaire. Quelques essais … Une petite modification dans la « sub EmptyTables » (on peut pas aller sur un controle non visible) et ça à l’air de tourner !! Donc bien sûr aucune erreur n’est piégée.
-------
Fichiers attachés : SuiviAffaire_MaJ_V1_V2 2007-06-23.zip (115,8 ko)
-------

[Papy Turbo]

Ce n’est pas un nettoyage que j’ai fait, mais j’ai mis tous les « ON ERROR GOTO CATCH » en commentaire.

Je comprends tes réticences, mais il faut bien comprendre que nous sommes ici dans le cas où seul le(s) développeur(s) d'origine vont utiliser l'application.
Ce cas n'est pas si rare, et permet de distinguer 2 familles d'applications :
On parle beaucoup, ici ou là, de la différence entre applications "PRO" et applications "amateur", souvent avec une notion de niveau de qualité.
Je préfère nettement distinguer :
- les applications "personelles", qui ne seront utilisées que par le(s) développeur(s), ou, en entreprise, par lui et ses collègues. Disons que les développeurs ne seront pas loin, et pourront toujours intervenir en cas de bug ou autre problème. J'en utilise quelques unes chez moi comme, je suppose, chacun de nous en a...
- les applications "professionnelles" sont, pour moi, celles qui seront distribuées à d'autres utilisateurs (les clients). Cela impose un niveau de stabilité et de sécurité très différent, du simple fait que les développeurs ne seront pas présents lors d'un bug ou problème. Entre autres, bien sûr, le contrôle d'erreur ne sera pas du tout le même.
L'exercice que tu viens de faire nous met donc dans le cas d'une application "personnelle". Peu importe qu'elle tourne en entreprise ou en privé, pour toi seul ou un petit groupe d'utilisateurs, l'essentiel est : tu ne vas pas la vendre ou la distribuer à des utilisateurs lointains, et, en cas d'erreur, tu seras sur place.
Ça ira très vite de remettre un contrôle d'erreur systématique à l'étape 3, pour en refaire une application "pro", avec, en prime, la librairie de l'étape 2.
D'où l'intérêt de simplifier au maximum, selon le principe suivant : pour réparer un bug, il faut pouvoir le reproduire. Quand tu es sur place, c'est encore + simple : un stop sur erreur (comportement par défaut de VBA) ou un Resume qui te remet directement dessus.

Maintenant, ça ne veut pas dire que tout est simple. Nous allons pouvoir insister sur les clauses Finally (en jargon .Net), que tu as très bien fait de garder

Petit aparté : Dans _Demarrage_Utilitaires > App_Init(), je rétablirais le ThisApp.Debugging = True, pour que notre application ne se ferme pas quand on ferme le formulaire.

Ensuite, je reprendrais chaque module, dans l'ordre des objets listés dans l'explorateur de projets (à gauche)
Je commence donc par Form_UpdateWizard:
Rien à redire sur les 3 premières routines.
Form_Resize : Premier cas particulier, avec clause Finally. Le cas où on n'a
- aucun traitement d'erreur spécifique,
- besoin d'exécuter une commande avant de sortir (Echo True, Docmd.Warnings True...)
est rarement abordé, et pourtant vital.
Dès qu'on fait un Echo False, il est impératif, avant de sortir, de refaire un Echo True.
Pour les utilisateurs d'Access 97, je rapelle qu'après un Echo False, on ne voit plus rien, même dans les fenêtres de code ! Les seuls moyens de s'en sortir sont :
- taper "à l'aveugle", un Ctrl+G (ouverture de la fenêtre d'exécution) suivi de "Echo True" et Enter.
- ou bien, faire comme ici : On error Goto Catch, suivi d'un Echo true imméditatement après l'étiquette Catch:
Pour Access 2000 et suivants, c'est moins grave, on voit quand même le code dans l'environnement VBA, puisque l'Echo False n'affecte que la fenêtre d'Access.
Mais je conseille quand même d'agir comme pour Access 97 en rétablissant tout de suite l'Echo True en cas d'erreur > beaucoup plus simple pour le débogage

Il faut donc réactiver le On error goto Catch (seulement ici) pour cette seule raison. Je supprimerais tout le reste : (Err).Raise... dont nous n'avons pas besoin pour l'instant.
Le contrôle d'erreur se réduit donc ici au strict minimum indispensable :

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
     On Error GoTo Catch 'nécessaire pour un Echo True, en cas d'erreur
    Echo False   '>>>>>>>>>>  TOUJOURS remettre Echo True, avant de sortir
 
    [... corps de la procédure]
'Finally:
    On Error Resume Next
    Echo True '>>>>>>>>OBLIGATOIRE>>>
    Exit Sub    '=========================================
Catch:
    Echo True '>>>>>>>>
    With Err
        Debug.Print .Number, .Description 'pour le développeur
    End With
    Stop    
    Resume  'on retourne sur l'erreur
End Sub

Attention au petit piège hyper dangereux avec les Resume : si tu supprimes le Stop ci-dessus, en cas d'erreur, tu obtiens une belle boucle sans fin !
J'ai gardé l'étiquette Finally: en commentaire, bien qu'elle ne soit pas utilisée, juste pour qu'on voit bien à quoi servent le On Error Resume Next et l'Echo True avant la sortie.
Même principe, dans cmdMAJTables_Click. Là, on doit faire un Docmd.SetWarnings True avant de sortir, quoi qu'il arrive. Sinon, toutes tes requêtes, même dans la fenêtre de base de données, s'exécuteront sans aucun message, les suppressions d'objets (table, requêtes, formulaires, états...) idem, donc attention les dégats !!!!
Même contrôle minimal : je remettrais juste le On Error Goto et on garde 2 fois Docmd.SetWarnings True : 1 pour la sortie 'normale', l'autre en cas d'erreur.
De +, on supprime, pour l'instant, l'enregistrement de l'erreur dans le journal, ainsi que les divers traitements qui étaient en commentaire, pour ne garder que le strict nécessaire.

Même chose avec la Sub EmptyTables. Tu y trouveras que l'ordre actuel des commandes, dans la section 'gestion d'erreurs', est pas terrible !

Dans le module suivant, _Demarrage_Utilitaires, il n'y a aucun traitement d'erreur : parfait.
Par contre, je repère au passage quelques routines qui seront bien utiles dans toutes nos applications : miam, miam, du code pour notre librairie, réutilisable, ça, c'est du bon code
Dans le module SpecificTransferRoutines, par contre, tu n'as pas fait ton boulot : dans BeforeTransfer, AfterTransfer et CleanupStringDoubles, faut tout supprimer (le On error goto, et tout ce qui se trouve entre le Finally: (inclus) et le End Sub...
Pas d'hésitation ni de regret, mzTools nous remettra tout ça en un clin d'oeil (et même mieux).

Idem, dans la classe clApplication, sub CheckTablesConnection.
Celle là inclut un autre type de traitement d'erreur spécifique, avec son Resume next suivi de test sur le n° d'erreur.
Il y manque juste un Case Else : on teste bien le cas où il n'y a aucune erreur, puis celui où on a les erreurs prévues (détectées pendant le débogage).
Il manque un Stop (pas besoin de resume, qui ne servirait à rien), en cas d'autre erreur, pas prévue...
Mais on peut supprimer définitivement le Catch: et tout ce qui le concerne.
Sans oublier que tout ce code là ira très bien dans notre librairie (re- miam, miam)

La classe clLog est nickel : aucun contrôle d'erreur.

Donc, à corriger pour les 3 premiers exemples, et finir de supprimer tout ce qui doit l'être, avant l'étape suivante : création de la librairie, qu'on va réutiliser aussi dans notre application principale.

[Serge57]

Donc, à corriger pour les 3 premiers exemples, et finir de supprimer tout ce qui doit l'être, avant l'étape suivante : création de la librairie, qu'on va réutiliser aussi dans notre application principale.

Donc joint l’application nettoyée.

Ton analyse entre « applications « personnelles » et applications « professionnelles" est juste. Mais pour faire une application « professionnelle » il faut avoir des connaissances approfondis du produit.
Je m’explique : Pour moi (en entreprise) « Access » est un produit qui me permet de faire de petite application rapide et facile à mettre en service (Gestion fournisseurs, Gestion Affaires, Gestion outillages…) avec un cahier des charges très ... très évolutif. La maîtrise du logiciel "Access" c'est faite sur le tas. Donc c’est vrai que le débogage ce fait à la volée. C’est pour çà que je suis assidument c’est cours. Merci pour ta patience !!!
-------
Fichiers attachés : SuiviAffaire_MaJ_V1_V2 2007-07-01.zip (112,6 ko)
-------

[Papy Turbo]

Hello,
d'abord, pour répondre à ton message qui illustre une des utilisations les plus courantes d'Access, un petit article à propos du contrôle d'erreurs, bref mais très instructif, sur le jdn :
IL Y A 5 ANS - 60 milliards de dollars par an pour les bugs américains
En bref,
- le coût global des bugs est réparti entre développeurs (1/3) et utilisateurs (2/3)...
- les bugs apparaissent principalement au début du développement, et ne sont identifiés majoritairement que dans la "dernière ligne droite", voire après la livraison...
Et j'ajoute : pour réduire les coûts, pas d'autre méthode que de tester aussi tôt que possible.
C'est simplement plus rentable, aussi bien pour le programmeur que pour le développeur, alors, si tu es les 2 à la fois
Bon, commercialement, c'est pas forcément le + rentable, mais c'est une autre histoire. Et, perso, j'aime mieux développer que déboguer...

Remarques sur le nettoyage du code : (voir ta dernière version. Les corrections sont dans le zip ci-dessous)
Form_UpdateWizard :
- Form_Resize impec, avec son Echo False qui sera restauré en cas d'erreur.
- cmdMAJTables_Click : même principe, avec son Docmd.SetWarnings False.
Quelques remarques :
1- (je chipotte, mais c'est pour bien illustrer le but de la maneuvre) : on n'a besoin du On Error Goto Catch seulement à partir du Docmd.SetWarnings..., pas avant. Donc, je l'ai déplacé plus bas.
2- en cas d'erreur non prévue, on remet bien le SetWarnings, mais il n'y a ni affichage de l'erreur, ni surtout de Resume qui va nous permettre d'identifier et de corriger l'erreur -> je remets le même traitement que dans Form_Resize.
Question : est-ce que ce petit traitement d'erreur, avec exécution d'une commande obligatoire, est bien clair ?
Sinon, indispensable de bien clarifier ces bases maintenant.

On continue :
- EmptyTables : idem cmdMAJTables_Click
Attention d'être rigoureux dans ce type d'exercice : pas d'à peu près. Un bug "un peu prévu" ou "un petit peu corrigé", ça reste un bug à traiter ou à corriger !

- erreur de Compilation : la sub CopieModeleBase a disparu de l'application ! Je l'ai récupérée de la version précédente : tu as peut être eu la main un peu lourde avec la touche supprime ?
Du coup, j'ajoute une
Manoeuvre indispensable : toujours recompiler tout le projet, après une modif quelconque, AVANT d'enregistrer le code modifié.
Pour ça, faire glisser la commande du menu Débogage > Compiler NomDuProjetsur la barre d'outils standard.
Je reviendrai, dans un résumé après la fin des cours, sur la disposition de l'interface, mais l'essentiel, ici, tient en 3 boutons, à faire glisser l'un à côté de l'autre, quelque part en plein milieu de la barre standard :
1- Débogage > Afficher l'instruction suivante (que j'utilise 20 fois par jour)
2- Débogage > Compiler NomDuProjet
3- Fichier > Enregistrer NomDuProjet(je sais, la disquette est déjà à gauche, mais je la veux juste à côté du bouton Compile -> en 2 clics, je compile + sauvegarde, après chaque modif de la moindre ligne de code !!!!!!!!!!!!)

Bien entendu, la barre mzTools indipensable, ainsi que Edition...

Je continue :
Modules standard : pas de remarque particulière, semblent bien popres.
classe clApplication :
- CheckTablesConnection : Pas de traitement d'erreur - bien, mais pourquoi un Exit Sub juste devant le End Sub ?
Par contre, 2ème cas typique : on traite les erreurs connues avec un Resume Next suivi de Select Case Err.number. J'ai juste ajouté un Debug.? Err; Err.description avant le Stop : c'est pratique d'avoir tout de suite le n° et message d'erreur.

Là aussi, il faut que ces notions de base (et les outils pour) soient parfaitement assimilés. Vaut mieux faire une pause et que ce soit clair, que continuer à l'aveugle...

Sinon, c'est bon.
La suite : même si on cause encore de contrôle d'erreur, tu peux commencer à réfléchir sur le code qui nous sera utile dans toutes nos applications, et qu'on va isoler dans une librairie (enfin, on y arrive Là, à long terme, tu vas gagner à la fois du temps ET des fonctionalités que tu ne mettrais jamais dans tes applis vite faites, mais qui seront toutes prêtes !!! Donc, des applis plus pros que chez pro !).
Dès le départ, on a ici, dans le moteur de mise à jour, une classe clApplication (avec son indicateur Debugging, etc.) + un journal (clLog) qui peut nous servir partout, ne serait-ce que pour enregistrer les messages d'erreur, avec, bien sûr, le nom du module, de la routine, et, pourquoi pas, le n° de ligne où l'erreur s'est produite.
Mais il y a aussi quelques routines de base telles que "copier un fichier" ou bien sûr, les APIs pour ouvrir un fichier...

La règle, à bien comprendre dès le départ, pour décider de ce qu'on met ou pas dans une librairie, est la suivante :
- on ne déplace que le code dont on a besoin (au moins) une 2ème fois.
En clair, quand on écrit une nouvelle routine pour la 1ère fois, on ne la crée jamais directement dans la librairie.
Il est impératif de la déboguer complètement avant. Pour cela, il faut qu'elle tourne dans les mêmes modules que l'application où on l'a créée, pour la simple raison que déboguer du code dans une librairie, c'était tout simple sous Access 97, mais, avec la séparation en 2 interfaces, à partir d'Access 2000, ça devient beaucoup plus lourd et complexe.
On en reparlera plus tard, parce que
- ça peut arriver quand même qu'on veuille modifier le code de la librairie, mais
- c'est très lourd et lent, donc ça doit rester exceptionnel.

Ceci dit, les quelques routines à notre disposition sont déboguées et doivent faire l'affaire.

Donc, simple : il y a plusieurs méthodes
- faire une copie complète de l'appli, la nommer "turbolib.mdb" ou ce que tu veux, et en supprimer tout ce qu'on ne garde pas dans la librairie (le code spécifique),
- exporter des modules entiers, et les réimporter dans la librairie,
- ouvrir les 2 et copier/coller d'une fenêtre à l'autre,
Dans tous les cas, après avoir extrait la librairie,
- supprimer son code de l'application d'origine,
- Outils > Références > choisir les fichiers '*.mdb' et créer une référence à la librairie.

S'il y a des problèmes, je suis là (serai absent en Août).

[Serge57]

S'il y a des problèmes, je suis là (serai absent en Août).

Voilà ma première librairie créée mais pas sans mal.
Une chose me chagrine, il me semble que l’objet de classe « clApplication » ne devrait pas se trouver dans la librairie, mais plutôt dans l’application elle-même ???.
( Je vais me faire tirer les oreilles ?? )
-------
Fichiers attachés : CreationLibrairie.zip (137,6 ko)
-------

[Papy Turbo]

Ben, écoute, tout d'abord, pour un premier exercice, clap clap , ça marche (et je me doute bien que ça n'a pas dû être évident).
Franchement, je m'attendais à bien pire.

Voilà ma première librairie créée mais pas sans mal.
Une chose me chagrine, il me semble que l’objet de classe « clApplication » ne devrait pas se trouver dans la librairie, mais plutôt dans l’application elle-même ???.
( Je vais me faire tirer les oreilles ?? )

Tirer les oreilles, non, parce qu'il n'y a que de bonnes questions, mais, pourquoi dans l'application plutôt que la librairie ?

Sinon, je remarque :
- dans le module _Demarrage_Utilitaires, que tu as transféré en entier dans la bibliothèque, il y a notre fonction App_Init(), qui contient pas mal de spécifique, comme le titre de l'application, le debugging On/Off, et la commande CheckTablesConnexion qui, d'une application à l'autre, va spécifier des bases et des chemins d'accès différents...
Donc, suivant les principes complémentaires que
- tout ce qui est réutilisable d'une application à l'autre est mieux dans la librairie,
- tout ce qui est dans la librairie devrait ne plus jamais (ou le moins possible) être modifié,
je garderais les 2 routines App_Init et App_Quit, qu'on pourra personaliser d'une appli à l'autre, dans l'application principale,
et je renommerais le module de la librairie, de manière à commencer un vrai stockage. Ce qui reste (fonctions publiques, réutilisables partout) concerne essentiellement les manipulations de fichiers, donc un nom du style lib_Files.
Plus tard, tu ajouteras des modules lib_Strings, lib_Mail, lib_Excel, etc..., mais c'est bien de s'organiser clairement dès le départ.

Là où je t'attends au tournant, c'est sur la création de l'objet ThisApp

Code :

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

1
2
Public ThisApp           As clApplication
    Set ThisApp = New clApplication

Ces 2 lignes, si tu les remets dans l'application principale, ne vont pas compiler.
Parce que, dans la librairie, la classe clApplication est déclarée comme Instancing = 1-Private.
Elle n'est donc pas visible depuis l'application.

On aborde là le sujet des limitations des librairies. Pas si compliqué que ça, mais indispensable de bien comprendre.
Limitation simple :
- on peut mettre des formulaires et des états dans une librairie, mais on n'y accède pas depuis l'extérieur (Docmd.Openform/Openreport ne les trouvera pas). Solution : créer, dans la librairie, une routine qui ouvre le formulaire.

Code :

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

1
2
3
public sub OpenForm(NomForm as String)
    Docmd.OpenForm NomForm
End Sub

C'est simplifié, mais tu vois que ce n'est pas sorcier.

Idem, pour nos classes contenues dans une librairie : on est coincé entre
- Instancing = 1-Private -> invisible à l'extérieur
- Instancing = 2- PublicNotCreatable -> Visible, mais, comme son nom l'indique, ne peut pas être créée depuis l'extérieur.
Dans VB6, il y a d'autres options, mais nous sommes limités à ces 2 là.
Solutions :
- on va déclarer les objets avec 2-PublicNotCreatable, pour pouvoir s'en servir
- on va les créer dans la librairie.
Pour les créer,
1- on pourrait, là aussi, créer une fonction qui renvoit l'objet
Dans la librairie,

Code :

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

1
2
3
Public Function CreateThisApp() As clApplication
    Set CreateThisApp = New clApplication
End Function

Dans notre application,

Code :

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

1
2
3
4
5
Public ThisApp As clApplication
 
Public Function App_Init()
    Set ThisApp = CreateThisApp()
End Function

2- on peut aussi la créer par défaut, en la déclarant avec le mot clé 'New' (indispensable : ouvrir l'aide et lire et relire tout ce qui concerne les objets, instances, le mot New, associé ou pas à Dim, Public, Private...)
Dans la librairie,

Code :

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

Public ThisApp As New clApplication

Dans notre application,

Code :

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

1
2
3
4
5
6
7
'aucune déclaration :o)
 
Public Function App_Init()
    With ThisApp 'et hop, dès le premier appel, l'objet est créé tout seul
        .Debugging = True
    End with
End Function

Je te laisse donc,
- nourrir la discussion sur le meilleur emplacement pour la classe clApplication,
- remettre les routines App_Init et App_Quit dans l'appli principale,
- faire que ça marche malgré les limitations ci-dessus.

Astuce : pour ce genre de test, c'est bien de mettre un Stop ou un point d'arrêt (F9) dans l'évènement Class_Initialize + Class_Terminate de la classe concernée (clApplication, mais aussi : clLog - même combat), pour savoir quand les objets sont créés/détruits.
Have fun

[Serge57]

Je te laisse donc,
- nourrir la discussion sur le meilleur emplacement pour la classe clApplication,

1 -Dans toutes applications, il me semble que la commande CheckTablesConnexion est utile. Bien sûr il faudrait la rentre plus neutre. Quelques variables supplémentaires à passer (extension du fichier, nom de la base..)
2 –Un journal me semble aussi utile dans chaque application.
Donc pour moi, clApplication et c1log devraient se trouver dans la bibliothèque.

- remettre les routines App_Init et App_Quit dans l'appli principale,

Ça OK (facile)

- faire que ça marche malgré les limitations ci-dessus.

Et voilà le HIC. J’ai suivi tes conseils, fait plein d’essais…. Mais rien compris.
D’après tes exemples cela ne paraît pas trop compliqué !! Mais à la compilation, j’ai des messages d’erreur du style variable non défini …. Mais là je crois que ce n’est plus mon manque d’expérience dans Access mais "Ma" non connaissance de VB6.

Donc, je demande de l’aide !!! Merccccccci

[Papy Turbo]

1 -Dans toutes applications, il me semble que la commande CheckTablesConnexion est utile. Bien sûr il faudrait la rentre plus neutre. Quelques variables supplémentaires à passer (extension du fichier, nom de la base..).

- Qu'entends tu par "+ neutre" ?
- Pourquoi "variables en plus ?"
Pour moi, on passe déjà le nom de la base, l'extension est toujours "*.mdb" (les connexions aux tables de projet Access *.adp sont complètement différentes -> bases ODBC, ça ne nous concerne pas ici.)

2 –Un journal me semble aussi utile dans chaque application.
Donc pour moi, clApplication et c1log devraient se trouver dans la bibliothèque.

Tout à fait d'accord, même si je me doute déjà que tu (ou n'importe quel utilisateur) pourra améliorer la méthode .CheckTablesConnexion, en fonction des besoins, à l'avenir.
On en profitera pour voir comment modifier le code d'une librairie, ce qui est un poil moins simple que de modifier un module sur place. Mais rien de terrible.

Et voilà le HIC. J’ai suivi tes conseils, fait plein d’essais…. Mais rien compris.
D’après tes exemples cela ne paraît pas trop compliqué !! Mais à la compilation, j’ai des messages d’erreur du style variable non défini …. Mais là je crois que ce n’est plus mon manque d’expérience dans Access mais "Ma" non connaissance de VB6.
Donc, je demande de l’aide !!! Merccccccci

Plusieurs choses, par (dés-)ordre d'importance :
- détail : ne pas confondre VB6 et VBA. L'idée de librairie et sa mise en place sont des fonctionnalités de VBA, avec variantes (format de projet lié...) d'une application à l'autre (Access, Word, VB6, Outlook, etc.)

j’ai des messages d’erreur du style variable non défini …

Là, par contre, je t'engueule :
- oui, nous sommes là pour déboguer,
- comment veux tu que je te réponde sans un message d'erreur précis : quelle variable n'est pas définie ?- et, à partir de cette variable : où est-elle définie (Dim ?,Public ?, New ?...) ? Quelle est sa portée ? (globale ? module ? projet ?)

La solution facile serait de te demander de m'envoyer la base, mais je préfère qu'on cherche ensemble, en public. C'est le but de l'exercice.
Donc, au boulot !

[Serge57]

La solution facile serait de te demander de m'envoyer la base, mais je préfère qu'on cherche ensemble, en public. C'est le but de l'exercice.
Donc, au boulot !

Avec beaucoup de retard, je me suis remis au boulot. Joint les modifications effectuées. Et ça à l’air de marcher.
-------
Fichiers attachés : SuiviAffaire_MaJ_V1_V2 2007-10-07.zip (158,5 ko)
-------

[Papy Turbo]

Un très très grand merci à Serge qui a servi de cobaye pour cette première expérience de cours "en direct", et bien sûr à tous les membres du forum et ceux de l'équipe Access qui ont apporté leur soutien et leurs commentaires, directement ou par MP.

Nous nous sommes amusés pendant près d'un an et demi, à survoler, sans aucun plan, les divers aspects de construction et mise au point d'une application de gestion type, avec base de données et interface.

Je vais maintenant, pendant les semaines/mois qui viennent, réexaminer tout ça pour voir ce qu'on peut concrètement en retirer. En gros, un exemple d'application type avec
- un formulaire type, (plein d'autres sont possibles)
- un début de bibliothèque pour stocker du code et des objets réutilisables,
- un journal d'erreur qui enregistre les erreurs non prévues,
- un moteur de mise à jour de la base, qui peut aussi servir de point de départ pour toute synchronisation ou autre import/export de données entre 2 bases relationnelles (.mdb ou autres).
- etc.

Tous commentaires sont bienvenus, essentiellement sur les méthodes de travail, bien sûr (pour les questions techniques, il reste le forum )

À plus...