Discussion :

[Papy Turbo]

>>>> Merci de noter toutes remarques concernant ce cours dans le sujet parallèle : [Cours papyturbo]Commentaires, remarques et suggestions
-------------------------------------------------------------------------
Ce cours est la suite
- du [Cours pt-01][Débutants]Analyse structure base de données simple et
- du [Cours pt-02][Débutants]Requête avec plusieurs sommes
- du [Cours pt-03]turbo-formulaire (les bases)
-------------------------------------------------------------------------
Le but de cet exercice est de choisir la meilleure méthode pour mettre à jour une base de données (le fichier .mdb contenant les données dans les tables), alors que nous (développeurs) avons
- développé une nouvelle application,
- modifié la structure des tables, de leurs indexes, leurs champs et des relations entre tables,
et que, pendant ce temps là, les utilisateurs ont continué à ajouter des données dans la version précédente.
Précision : Même si je suis le seul utilisateur d'une application dont je me sers tous les jours, il n'est pas question de modifier l'application avec laquelle je réalise mon travail quotidien : un bug surviendra toujours au pire moment critique, lorsqu'un client t'appelle pour avoir l'info indispensable tout de suite .
Je conseille donc de développer toujours sur des copies de l'application et des copies de la base de données, puis de faire une installation avec mise à jour de la BDD.

Nous allons utiliser les éléments suivants, chacun correspondant à un fichier ".mdb" :
- base de données (tables) à la version 1 : en cours d'utilisation. Nous allons utiliser une copie, pour les tests.
- base de données (tables) à la version 2 : nouvelle structure, à mettre en production.
- application, version 2 : à mettre en production, ici par simple copie.
- le moteur de mise à jour V1 > V2 : une mini-application Access que nous n'utiliserons qu'une seule fois.
J'ignore l'application, version 1, qui sera écrasée par la copie de l'application, version 2, pendant l'installation.
À noter, que, dans le zip ci-joint, l'application a été "splittée" en 2, en utilisant l'assistant d'Access (menu Outils > Utilitaires de base de données > Fractionner une base de données), pour séparer toutes les tables, sauf bien sûr, la table [Affaires_Selection] qui doit impérativement être une table locale, propre à chaque utilisateur (sinon, je te laisse imaginer l'embrouille ! )

Il y a 2 méthodes possibles pour réaliser cette mise à jour :
méthode #1 : reporter dans la base de données active (V1) toutes les modifications que nous avons mises au point et testées dans la base V2.
méthode #2 : créer un modèle de base en vidant les tables de la base V2, et transférer dans ces tables vides toutes les données existantes, depuis la base V1.

Quelle que soit la méthode, il va falloir interrompre les utilisateurs pendant la mise à jour : le moins longtemps possible, of course.
Une mise à jour très complexe, concernant quelques dizaines de tables, chacune ayant de 100 à quelques dizaines de milliers d'enregistrements, ne dépasse jamais quelques minutes : rarement 5 minutes, à moins que certaines opérations exigent une intervention de l'utilisateur pour faire des choix...

Je n'ai jamais utilisé la méthode #1, sauf s'il s'agit d'ajouter un seul nouveau champ dans une table, ou une nouvelle table dans la base.
Le principal argument en faveur de la méthode #2 est que je n'ai jamais été capable de faire une liste exhaustive et complète des modifications apportées à une base de données, dès que ces modifications sont un peu complexes.
Il y a toujours quelque part un index ou une propriété oubliée...

Le fonctionnement de la méthode #2 est par contre assez simple dans son principe :
- nous allons traiter chaque table dans l'ordre des niveaux d'intégrité référentielle (détails ci-dessous),
- pour les tables sans modifications majeures, une requête ajout (INSERT INTO) va transférer toutes les données de la V1 à la V2,
- nous allons contrôler les erreurs : essentiellement en comparant le nombre d'enregistrements transférés dans la V2, avec ceux de la table V1.
S'il en manque, nous ajusterons la requête pour tenir compte de chaque cas, ou nous mettrons en place des transformations plus complexes, avec une table locale intermédiaire, par exemple.
- nous recommencerons jusqu'à ce que toutes les données soient correctement transférées.
- nous passerons alors "en production" : installation de la nouvelle application + mise à jour de la base contenant les dernières données réelles.

Niveaux d'intégrité référentielle :
Cette notion, rarement mentionnée dans l'aide ou les ouvrages sur les bases de données, est primordiale pour tout transfert de données (mise à jour, synchronisation, extraits...) : nous ne pourrons pas, par exemple, copier les Affaires (niveau 1 d'intégrité) dans la base V2 si nous n'avons pas d'abord transféré tous les Clients (niveau 0).
La relation d'intégrité entre les tables Clients et Affaires de la V2 nous empêcherait d'ajouter une affaire avec une IdClients qui ne correspond à aucun client dans la table Clients.
Bien sûr, seules les règles d'intégrité de la base V2 nous concernent : celles de la base dans laquelle nous allons écrire.
Et, bien sûr toujours, il est impératif de ne jamais rien modifier dans la V1, pour pouvoir revenir en arrière, en cas de problème non prévu.

C'est pour clarifier cette notion de niveaux que je conseille toujours très vivement de disposer, dans les schémas de relations (menu Outils > Relations...),
- à gauche, les tables auxquelles n'aboutissent aucune relation, (niveau 0)
- immédiatement à leur droite, en colonne, les tables qui dépendent des premières par une relation, (niveau 1)
- continuer ainsi, de la gauche vers la droite, en alignant autant que possible les tables les unes sous les autres, par niveau.
C'est aussi pour cette raison que j'ai utilisé Excel comme outil de dessin, dans la réponse #31 du cours 01. Ça me permet de mettre clairement en évidence les numéros, comme dans le schéma ci-dessous (qui, attention, ne correspond plus à notre base V2 , mais plutôt à la V1 ) :


La toute première étape qui consiste à
- créer une base vierge pour le moteur de mise à jour (fichier SuiviAffaire_MaJ_V1_V2 2006-11-06.mdb),
- attacher toutes les tables de la V1 et celles de la V2, (Fichier > Données externes > Lier les tables...)
- différencier les tables en ajoutant le n° de version "_1" ou "_2" derrière chaque nom,
est faite, dans le zip ci-joint.

Il va donc falloir pour toi :
1- utiliser le gestionnaire de tables attachées (Outils > Utilitaires de bases de données > Gestionnaire de tables liées...) pour réattacher les tables correctement, en fonction de ton chemin d'accès,
2- me corriger (chacun son tour ) en vérifiant que les fichiers ci-joint correspondent bien aux bases de données de la version 1 (en cours d'utilisation) et 2 (celle que nous avons mise au point).
Note : tu pourras supprimer l'application (fichier SuiviAffaire_App 2006-11-06.mdb) du fichier zip. Elle ne nous intéresse plus, dans le cadre du cours 05. dans les prochains échanges, seul le moteur de mise à jour (fichier SuiviAffaire_MaJ_V1_V2 2006-11-06.mdb) devrait être modifié et zippé.
3- faire une liste complète des tables de la V2, en indiquant, pour chaque table, le niveau d'intégrité référentielle.

[Serge57]

2- me corriger (chacun son tour) en vérifiant que les fichiers ci-joint correspondent bien aux bases de données de la version 1 (en cours d'utilisation) et 2 (celle que nous avons mise au point).

J’ai repris toutes les tables de la version 1 avec correction.

Quelques commentaires sur les tables de la version 1 par rapport à la version 2.
‘Personnel’ --> ‘Employé’.
‘AvancementEtudeFournisseur’ --> ‘HeurePassee-SectionAffaire-Fournisseur’.
‘AvancementEtudePersonnel’ --> ‘HeurePasseee-SectionAffaire-Personnel’.
‘Date/Semaine’ --> ‘Date-Semaine’.
‘HeureFournisseurAffaire’ --> ‘Fournisseur-SectionAffaire’
‘HeurePersonnelAffaire’ --> ‘Personnel-SectionAffaire’.
‘HeuresAllouées’ --> HeureAllouees-SectionAffaire’.
‘SectionPerFou’ --> Section.

Joint le fichier : SuiviAffaire_Maj_V1_V2 2006-11-08.zip contenant (pour que nous travaillons sur les mêmes fichiers)
1- NI_V1.xls : Schéma du niveau d’intégrité référentiel de la version 1.
2- NI_V2.xls : Schéma du niveau d’intégrité référentiel de la version 2.
3- SuiviAffaire_BDD_V1.mdb : Base version 1.
4- SuiviAffaire_BDD_V2.mdb : Base version 2.
5- SuiviAffaire_MAJ_V1_V2 2006-11-08.mdb : début de la base de mise à jour.
-------
Fichiers attachés : SuiviAffaire_Maj_V1_V2 2006-11-08.zip (62,6 ko)
-------

[Papy Turbo]

Tu vas t'occuper très bientôt des tables qui ont changé de nom, donc très bonne liste.
La première tâche, pour l'instant, est de créer un modèle de base de données vide et propre, au format des nouvelles tables.
Il faut donc :
- conserver une base de données version 2 avec des données dedans, au cas où on aurait encore des tests à faire sur notre application, version 2.
- utiliser une copie, que nous allons vider.

Comme je suis flemmard, je n'ai aucune envie de créer une requête pour vider chaque table. Je préfèrerais créer un assistant qui fasse le boulot aussi automatiquement que possible.
Tu trouveras
- une requête type, utilisée comme test et pour copier son code SQL dans le code VBA : *** Test suppression données
- une nouvelle table, locale, intitulée [000 DestinationTables]. Son index est basé sur le niveau d'intégrité de chaque table + le nom de la table. Je suppose que tu devines pourquoi ?
Les champs de la table devraient être évidents :
- niveau d'intégrité, J'ai suivi ton schéma NI_V2.xls pour noter les niveaux d'intégrité de chaque table.
- nom de la table,
et un nouveau
- champ DataTable, format Oui/Non, pour distinguer les tables de données des tables dites "de paramètres" ou "de données fixes".
Les tables "de données" sont celles dont nous allons récupérer les contenus à partir de la version 1.
Les tables "de paramètres" sont celles dont le contenu ne peut pas être changé par les utilisateurs.
Exemple :
À toi de décider si ton application SuiviAffaires permet ou non de créer des nouvelles sections ?
- si oui, la table Sections est une table de données, comme les autres.
- si non, tu es le seul à ajouter/supprimer/renommer ces sections et la table Sections de la version 2 doit être laissée telle quelle, avec toutes les sections dedans.
Tu trouveras également :
- un formulaire UpdateWizard, qui contient
- un onglet tabWizard, qui contient 2 pages :
... la 1ère page, Nettoyage modèle n'intéresse que nous, les développeurs, pour préparer un beau modèle de base vide.
... la 2ème page, Transfert, sera visible lorsque nous enverrons cet "assistant d'installation et mise à jour de la base de données" à notre client. Lui n'aura pas besoin de vider les tables, parce que nous lui donnerons seulement le modèle propre et vide.
Je sais que tu portes les 2 casquettes, mais il est utile pour tous les autres de bien séparer les tâches "développeur" des tâches "utilisateur/installateur".
En situation réelle, il sera facile de masquer la 1ère page avant d'envoyer l'assistant à un utilisateur.
- l'onglet Nettoyage modèle contient un sous-formulaire ssfDestinationTables basé sur la nouvelle table, et un bouton qui vide toutes les tables.
Le code de ce bouton devrait être clair ?
La seule particularité est peut être le DoCmd.SetWarnings : permet de supprimer les messages d'avertissement de Jet, lors de l'exécution d'une requête SQL. À maintenir actif pendant le débogage, pour voir et corriger les problèmes, puis à éteindre(False) lorsque le code est correct.

J'ai également ajouté, dans le module VBA, une référence à DAO, et supprimé la référence à ADO (ActiveX Data Objects), dont nous n'aurons pas besoin. En VBA, voir menu Outils > Références.

À part cela, le reste devrait être limpide :
- on travaillera toujours à partir des tables de destination, celles dont les règles (d'intégrité, d'indexation avec/sans doublon, de champs nulls admis/refusés, etc.) devront être respectées,
- on ne peut vider ces tables qu'en commençant par le dernier niveau d'intégrité. Pause : la raison est évidente ?
- il reste un mini-bug , à résoudre avant de supprimer les Stop et autres commentaires destinés au débogage.
Le mini-bug est juste là pour mette en évidence la méthode générale :
On avance pas à pas, en essayant bêtement de "faire le travail" (vider toutes les tables de données, puis copier leurs contenus...).
À chaque étape, on lance le processus complet, et on corrige les erreurs au fur et à mesure qu'elles apparaissent.
Cette méthode plante nécessairement au début, mais elle va beaucoup plus vite que d'essayer de tout prévoir d'avance. Ça sera encore + évident + tard, quand ça va se compliquer...

Bref, le travail pour toi va consister à
- réparer le dernier bug qui plante,
- préparer la prochaine étape : juste un bouton Mise à jour dans le 2ème onglet, qui va transférer toutes les données depuis chaque table de la version 1 dans chaque table de la version 2.
Tu peux reprendre le modèle de code que j'ai utilisé pour vider les tables, évidemment en inversant l'ordre des tables (c'est bien clair, ça ? )
En remplaçant le code de la requête SQL de Suppression par une requête Ajout, qui copie toutes les données d'un table V1 dans la même table V2.
Tu vas avoir des problèmes, ne serait-ce que dès qu'une table aura changé de nom : pitête qu'un nouveau champ dans la table 000 DestinationTables, genre un champ SourceTableName, pourrait résoudre ce 1er problème ?

N'essaye pas de résoudre tous les problèmes d'un coup : pour l'instant, juste un transfert standard, très générique, qui ne marchera correctement que pour les tables dont les champs n'ont pas changé.
Rappel : ici, nous avons volontairement fait de profondes modifications à la structure de la base. En temps "normal", seuls un nouveau champ par ci-par là, ou quelques nouvelles tables... nécessiteront un traitement spécial. Mais la plupart des tables ne changent pas d'une version à l'autre.
Commençons donc avec cette routine générique qui fera le gros des transferts.
Bon courage.
Et si tu es bloqué, suffit de crier très fort.

P.S. : je suis gentil : je ne t'ai pas demandé de faire un Form_Resize du formulaire, de l'onglet, du sous-formulaire... bien que tu saches maintenant faire ça en 2 minutes.
Parce que c'est juste un outil qui va tourner une seule fois.
Mais si tu veux faire l'exercice, faut pas te gêner.

[Serge57]

Une initiative : Renommer toutes les tables en mettant le numéro de la table en tête du nom de la table (plus facile et moins de risque lors de la sélection pour ‘gestion des tables liées’). Donc reprise du code ‘Vider les tables de données’.

À toi de décider si ton application SuiviAffaires permet ou non de créer des nouvelles sections ?

Normalement elle permet, mais pour l’exemple on peut dire que NON.

... la 1ère page, Nettoyage modèle …

Etape fonctionnelle.

... la 2ème page, Transfert,

Création d’un champ supplémentaire dans la table 000_destinationTables (SourceTableName) pour y rajouter les noms des tables Sources.

Création d’une requête pour nouveau sous formulaire ‘FUpdateWizard_002_TransfertData’ pour la lecture de la table source et table destination.

Création d’un sous formulaire ‘UpdateWizard_002_TransfertData’ et insertion dans le 2ème onglet du formulaire ‘UpdateWizard’.

Dans le 2ème onglet rajout d’un bouton de commande ‘cmdMAJTables ‘ Mise à Jour Tables.

Puis je suis bloqué ( cause des différents nom de champ dans les tables).
J’ai envisagé une solution : création d’une table du même style que ‘000 DestinationTables’ mais cette fois avec la liste de tous les champs ??

Donc avant de continuer je crie très fort !!!

-------
Fichiers attachés : SuiviAffaire_MaJ_V1_V2 2006-11-14.zip (29,3 ko)
-------

[Papy Turbo]

Une initiative

1ère bonne surprise !
Ça veut dire que tu commences à être à l'aise, donc continue comme ça.
Il vaut mieux plein d'initiatives, quitte à te planter : il n'y a que comme ça qu'on apprend !

Sur ce point, l'inconvénient de mettre le numéro de version avant, c'est que j'aime bien avoir la table version 1 + la même, version 2, + selon les besoins une 3ème table, locale, temporaire, qui porte le même nom.
Tu verras donc toi même, au bout de quelques essais, ce que tu préfères : version par devant ou par derrière (sur l'air de ...)

2ème bonne surprise : le redimensionnement des formulaires marche impec ! C'est top, et ça va nous permettre d'ajouter encore des champs à notre "table des tables".

Diverses retouches :
J'ai réactivé l'Echo False, au début de Form_Resize : c'est nettement plus agréable,sans le scintillement.

Par contre, je ne sais pas si on va avoir besoin de 2 copies du sous-formulaire et de la table des tables ?
Une seule devrait suffire, pourvu qu'on ait tous les champs, et, a priori, inutile d'afficher ça aux utilisateurs de l'installation.
En tout cas, il faudra qu'ils ne puissent rien modifier.
On reverra ça plus tard. Pour l'instant, on peut s'en servir pour montrer l'avancement, table par table.

Dans le code VBA du formulaire, tri des routines : j'ai utilisé la commande de mzTools : Autres utilitaires > Trier les procédures.
De manière à avoir, en tête, tous les évènements du formulaire, suivis, dans l'ordre, de nos 2 boutons. (hé oui, je suis maniaque !)

Contrôle d'erreur : comme dans Form_Resize, qui doit impérativement faire un Echo True avant de sortir, nous devrons impérativement, au delà de la phase de débogage, faire un SetWarnings True.
J'ai donc recopié le code de contrôle d'erreur de Form_Resize, pour être sûr de toujours exécuter cette commande, même si une erreur imprévue se produit.

Formulaire principal (conteneur) : supprimé le sélecteur d'enregistrement (y a pas d'enregistrements), et les boutons de navigation.

cmdMAJTables_Click : planté
Quand on supprime des enregistrements, on commence par le dernier niveau d'intégrité, et on remonte vers le premier.
Quand on ajoute, ou qu'on modifie des enregistrements, on commence par le niveau le plus bas (0), et on remonte.
Il faut que cette notion devienne évidente.
C'est la conséquence logique de l'intégrité : pas d'Affaire qui ne corresponde à aucun Client... donc
- suppression des Affaires d'abord, puis suppression des Clients,
- ajout des nouveaux Clients en premier, suivi de l'ajout des Affaires.

En ce qui concerne notre transfert de données, j'ai rien fait !
Je suis trop flemmard (je me répète, mais je pense que tout bon développeur est un flemmard qui préfère faire travailler son ordi, plutôt que de faire le travail "a la main") pour
1- reconnecter les tables une par une, même avec le gestionnaire de tables attachées,
2- noter tout ce qu'il se passe, et surtout les messages d'erreur.

Tu trouveras donc un ensemble de classes objet (j'espère que ça te fait peur ) et de modules, dont certaines routines importées directement de la FAQ Access (à consommer sans modération) :
Dans l'ordre où ils s'exécutent :
- une macro Autoexec qui lance une routine d'initialisation : App_Init(). Cette routine initialise les objets dont nous avons besoin.
- un module _Demarrage_Utilitaires qui, comme son nom l'indique, contient les routines de démarrage (App_Init(), et de fin : App_Quit() qui ferme proprement les mêmes objets) + divers utilitaires dont nous aurons besoin,
- une classe clApplication, qui va servir à créer un objet ThisApp, auquel on va donner toutes les propriétés et les méthodes qu'on ne trouve pas dans l'objet Application d'Access : un nom, un titre, même un journal, etc. selon les besoins...
- une classe clLog (Log = journal) qui va servir à créer le journal dont dispose notre nouvelle application (objet ThisApp.Log).

Les codes extraits de la Faq sont déjà commentés dans la Faq.
Y a t-il besoin de commentaires sur les différences entre un module de classe et un module ordinaire ?
Disons seulement que je me suis permis d'ajouter des propriétés (Name, Title...) directement en tant que variables Publiques, en tête du module de classe, alors qu'il existe une méthode + lourde, avec Property Get et Property Let...
Mieux vaut voir les divers cours d'initiation aux classes, dans la rubrique Cours de Développez, entre autres :
- Création d'une classe de manipulation de chaînes de caractères
- Tout comprendre à propos des modules de classes sous Access
- La notion de la classe formulaire Access par l'exemple
etc.
Je passe sous silence la classe "Images" de Thierry Gasperment, qui est nettement plus tordue...)

Il y a déjà une routine pour reconnecter les tables dans la FAQ : Rétablir les liaisons des tables liées après déplacement d'une base fractionnée par Tofalu.
Celle qui figure dans la classe clApplication, la méthode CheckTablesConnection() fait un poil plus de travail pour automatiser cela, dans le cadre d'une application Access standard (toutes mes applications démarrent par une routine beaucoup plus complexe que celle-là, mais qui fait à peu près la même chose) :
- elle parcourt les tables,
- elle ignore les tables locales,
- elle vérifie si les connexions sont bonnes en essayant d'ouvrir chaque table attachée,
Dès qu'elle en trouve une dont la connexion est rompue,
- elle extrait le nom de la base concernée (nous sommes ici connectés à 2 bases distinctes)
- elle ouvre une boîte de dialogue pour demander où se trouve la bonne base à rattacher,
- et elle reconnecte toutes les tables qui étaient liées à la même base (ça, c'est le seul point qui m'intéresse en temps que flemmard professionnel )

Tout ça pour quoi ?
En dehors de la reconnexion des tables, tu constateras, dans la routine cmdEmptyDataTables_Click() quelques retouches : il y a notamment un journal qui se crée dans le même dossier que l'application, pour noter, soit les erreurs, s'il y en a, soit le bon déroulement de notre mise à jour.
Je te laisse donc, pour l'instant,
1- digérer les nouveautés (bon appétit),
2- appliquer la même méthode à ta routine cmdMAJTables_Click()
Le but à atteindre :
- que tout s'exécute, même s'il y a des erreurs,
- qu'on puisse ensuite ouvrir le journal et voir quelles sont les tables dont les données ne sont pas passées.
Pour cela, il serait bien de
1- avoir un On Error Goto qui enregistre les erreurs (Number, Description) dans le journal, avec le nom de la table concernée, puis qui continue quand même (Resume Next),
2- avec ou sans erreur, dans le journal, après exécution de la requête SQL Ajout, de
- comparer le nombre d'enregistrements de la table V1 avec celui de la table V2,
- s'ils sont égaux, OK - TVTB
- s'ils sont différents : *** erreur !!!

On verra alors, une par une, comment les traiter (requête spécifique, code...)
Dans un cas réel, comme je l'ai déjà dit, seules quelques tables seront modifiées et "ne passeront pas" : la méthode avec journal permet de les identifier, sans se préoccuper des autres. C'est le but de cet exercice : te faire gagner du temps à chaque fois que tu recréeras un moteur de mise à jour à partir de ce modèle, pour les prochaines versions de SuiviAffaires, ou autres applis.

[Serge57]

Quand on supprime des enregistrements, on commence par le dernier niveau d'intégrité, et on remonte vers le premier.
Quand on ajoute, ou qu'on modifie des enregistrements, on commence par le niveau le plus bas (0), et on remonte.
Il faut que cette notion devienne évidente.

J’avais compris, mais n’étant pas un virtuose de VBA, (j’ai pas vu ‘.MoveLast’ dans le code), j’avais fait un tri décroissant dans la requête ‘FUpdateWizard_002_TransfertData’ et ça avait l’air de marcher !!!!

1- digérer les nouveautés (bon appétit),

mal à l'estomac ! (mais enfin j'ai signé pour ça )

2- appliquer la même méthode à ta routine cmdMAJTables_Click()

1- avoir un On Error Goto qui enregistre les erreurs (Number, Description) dans le journal, avec le nom de la table concernée, puis qui continue quand même (Resume Next),

J’ai appliqué la même méthode .

2- avec ou sans erreur, dans le journal, après exécution de la requête SQL Ajout, de
- comparer le nombre d'enregistrements de la table V1 avec celui de la table V2,
- s'ils sont égaux, OK - TVTB
- s'ils sont différents : *** erreur !!!

Pour l’instant aucune table ne passe sont erreur (problème de nom de champ, de table inexistante, ….)

Ci joint Application avec un embryon de code pour la commande cmdMAJTables_Click ?? pour gestion dans le journal et correction. (c'est une idée de code .
-------
Fichiers attachés : SuiviAffaire_MaJ_V1_V2 2006-11-17.zip (66,0 ko)
-------