Leçon 59 : Création d'une table des élèves, renommage des tables et son implication, requête Ajout

Temps nécessaire pour suivre cette leçon : Entre une demie heure et trois quarts d'heure

Pour suivre cette leçon, vous devez avoir suivi les leçons précédentes. Ou plus précisément, vous devez être en possession de la base de données ProFormation.mdb telle qu'elle était à la fin de la leçon précédente. Si vous n'êtes pas certain de l'avoir, vous pouvez la télécharger ici

Aperçu de cette leçon

Dans cette leçon, nous allons séparer la table des élèves pour en faire une table à part, pour des questions de convivialité, de souplesse et de sécurité. Comme il s'agit d'une grosse opération, cette leçon n'abordera que la première partie de ce transfert. Nous verrons notamment l'utilité de la requête Ajout, qui est une requête de type Action.

Sommaire

Problèmes inhérents au renommage d'une table ou d'un sous-formulaire
Propriété de formulaire : Source
Problèmes de renommage partiellement résolus avec Access 2000
Rappel de la fonction de la clé primaire
Requête action de type Ajout
Différence entre Visualiser et Exécuter une requête
Mise en garde quant à l'exéction multiple d'une même requête action

Comme vous l'avez vu, ce n'est pas très pratique ni très professionnel d'avoir la liste de nos élèves faisant partie d'un cours simplement sous la forme d'un champ qui contient à la fois le nom et le prénom de l'élève : Risques d'erreurs, saisie ennuyeuse, fautes d'orthographes :

. L'idéal, vous en conviendrez, ce serait d'avoir une liste déroulante pour choisir les élèves, comme ceci :

Problèmes inhérents au renommage d'une table ou d'un sous-formulaire

Oui : Il nous faudrait une table des élèves alors ? Une table qui contiendrait tous les élèves possibles, un peu comme on avait fait la table des pays à la leçon 15 ?

C'est exactement ça. En fait, ici, ce ne serait pas exactement une table des élèves, mais plutôt une table des employés, puisque nous imaginons toujours que vous êtes responsable des formations internes à une entreprise.

Avant de commencer quoi que ce soit, nous allons donner un nom un peu plus "propre" à notre table T_Eleve : En fait, pour éviter de la confondre avec une éventuelle table des élèves complète, qui contiendrait justement la liste de tous les élèves possibles, vous allez renommer donc cette table T_Eleve en T_CoursDetail qui me parait plus parlant

. Vous vous souvenez comment faire pour renommer une table ? C'était à la leçon 12.

ATTENTION : Maintenant que vous avez renommé la table, le formulaire F_EleveSF ne fonctionne plus :

C'est normal puisqu'on a changé le nom de la table qui lui servait de source...

Oui, c'est vrai, mais ici c'est facile car je vous ai mis le doigt immédiatement sur le problème : Vous auriez été seul, vous auriez pu renommer la table et ne pas du tout vérifier si le reste continuait à fonctionner... Et tout à coup 3 jours plus tard, vous tombez sur cette erreur, vous allez être un peu décontenancé, non ?

Oui, c'est vrai..

Propriété de formulaire : Source

Donc, maintenant, nous allons remédier à ce problème. Nous allons préciser que la table Source de F_EleveSF n'est plus T_Eleve, mais T_Cours Detail :

Fermez les propriétés et lancez le formulaire en mode saisie de données : Tout est rentré dans l'ordre.

Pendant qu'on y est, pourrait-on renommer F_EleveSF en F_CoursDetailSF ?

Mmmmh... Peut-être que le formulaire principal F_Cours ne reconnaîtra plus le sous-formulaire ?

Effectivement, j'ai l'erreur suivante :

Eh oui... Une erreur un peu du même genre que celle d'avant. F_Cours s'ouvre bien, mais en lieu et place du sous-formulaire, il n'y a plus qu'un grand rectangle blanc :

Voici comment remédier à cet état de fait (Re-préciser le nom du formulaire servant de source au sous-formulaire) :

Problèmes de renommage partiellement résolus avec Access 2000

Access pourrait quand même faire les changements lui-même ! C'est stressant de devoir tout faire à la main ! On peut toujours oublier une chose ou l'autre, et il n'y a plus rien qui marche. Et encore, là c'est facile parce que vous me guidez, mais sinon, c'est la galère !

Oui. Mais Microsoft essaie de faire des efforts. Dans certains cas de figure, mais qui me paraissent assez aléatoires, Access 2000 change certaines choses automatiquement, contrairement à Access 97 qui ne fait vraiment rien lui même. Peut-être qu'Access XP fait encore mieux, je n'ai pas testé...

C'est quoi qu'Access 2000 change automatiquement ?

Je ne sais pas exactement. Par exemple, quand j'ai renommé la table ou le sous formulaire, je me suis demandé s'il allat faire les changements nécessaires, mais non... Parfois il lui arrive de le faire. Mais je n'en sais pas plus. Peut-être qu'avec les noms de champs, il y a plus de changement dynamique. A tester, mais comme je vous ai dit, ça ne me parait pas très stable. Mieux vaut tout vérifier à la main en cas de changements.

Tout ceci pour finalement créer une table de tous les élèves potentiels, qui sera en fait T_Employe.

Disons... Le nom, le prénom, et peut-être le téléphone interne et la date de naissance par exemple

Voilà. d'accord.... On pourrait aussi ajouter dans quel service il travaille, la couleur de sa cravate, enfin bref... Disons que nous allons retenir votre proposition. Vous allez donc créer une nouvelle table T_Employe (Leçon 3) avec les champs suivants :

. Tout est en texte 50 (Leçon 6), sauf la date de naissance en Date/Heure (Leçon 7). Mettez aussi les légendes pendant que vous y êtes : Nom, Prénom, Tél. interne et Date de naissance (Leçon 4).

Je ne crois pas non ...

Non ?...

Parce que quand tout à l'heure nous allons générer notre liste déroulante dans T_CoursDetail, il va bien falloir stocker un champ de notre table T_Employe dans T_CoursDetail : Ce sera lequel ? NomEmploye ? Prenom ?

Rappel de la fonction de la clé primaire

Et bien le nom et le prénom, non ?

Non. Vous avez droit à UN SEUL champ de T_Employe. C'est pour ça que nous allons ajouter une clé primaire. Et comme on ne peut pas l'installer sur le nom (il peut y avoir des homonymes), ni sur le prénom (évidemment), vous allez ajouter un IDEmploye en NuméroAuto au dessus de tout le monde :

Mais comme c'est un NuméroAuto, on est donc absolument certains qu'il n'y aura JAMAIS 2 fois le même numéro. Pourquoi est-ce que je passe mon temps à en plus ajouter une clé primaire ?

Ah ça je sais ! C'est parce que si IDEmploye n'est pas une clé primaire dans T_Employe, comme tout à l'heure nous allons également installer un IDEmploye dans T_CoursDetail pour faire la liaison avec cette table, si je ne met pas de clé primaire, donc, on ne pourra pas faire de relation avec intégrité référentielle (Leçon 16) entre les deux tables !!!

Enregistrez votre table. Maintenant, il s'agit de la garnir : Mettre les employés. Vous les connaissez ?

Non...

Si si ! Vous en connaissez quelques uns : Ce sont les élèves de T_CoursDetail : Bernard Bracaillon, Alice Japren, ...

Requête action de type Ajout

Ah oui ! Et on pourrait les récupérer depuis T_CoursDetail pour les injecter dans T_Employe ?

Oui. Mais attention, ce n'est pas si simple. Allons y doucement. Pour passer des données d'une table dans une autre, nous allons utiliser une requête de type Ajout. Ca se passe comme ça :

Créez une nouvelle requête basée sur T_CoursDetail (Leçon 21). Placez-y le champ IdentiteEleve uniquement :

(Dans notre cas, IDCours, on s'en fiche). Si vous exécutez la requête, vous abtenez simplement la liste des élèves inscrits aux cours :

. Mais nous ne voulons pas les AFFICHER... Nous voulons les INJECTER dans T_Employe. Pour ce faire, nous allons donc utiliser une requête de type Ajout. Facile ! En mode création de votre requête, c'est juste ici :

. Dès que vous avez choisi Requête Ajout, il vous demande dans QUELLE table vous voulez ajouter les données ? : Dites que c'est dans T_Employe :

, et cliquez sur OK. Maintenant, votre requête à un tout petit peu changé :

Il y a donc une nouvelle ligne "Ajouter A"... Eh oui, c'est logique ! Parce qu'il y a plusieurs champs dans T_Employe (Nom,. Prenom, Tel et date de naissance)...

Ah ben le nom dans le nom et le prénom dans le prénom, évidemment !

Comme vous y allez ! Ce n'est pas si simple : Dans T_Cours Detail, il y a UN SEUL champ : IdentideEleve, qui contient à la fois le nom et le prénom de l'élève, on fait quoi maintenant ?

Mhhh... On aurait dû y penser avant...

C'est malin !

Différence entre Visualiser et Exécuter une requête

Pour l'instant, nous allons simplement transférer ce champ IdentiteEleve dans NomEmploye, même si c'est faux. Facile :

. Et maintenant attention : Dans votre barre d'outils, il y a DEUX icônes :

que j'appellerai donc icône 1 et icône 2. Si vous cliquez sur l'icône 1, vous allez simplement visualiser le résultat le la requête, comme vous avez l'habitude (Vous pouvez essayer). Mais l'icône 2 va EXECUTER cette requête de type ajout : Elle va REELLEMENT copier tous les IdentiteEleve jusque dans la table T_Employe. Essayez : Cliquez sur l'icône 2 :

. Il vous informe qu'effectivement, il va prendre les 15 personnes présentes et les copier dans l'autre table. Et, comme il vous le dit, vous ne pourrez PAS annuler le changement ainsi fait. Bon ici, ce n'est pas bien grave, parce que si on n'est pas satisfait du résultat, on pourra toujours aller effacer ce qu'il nous a ajouté dans l'autre table. Répondez donc Oui : HOP, c'est fait.

On va aller vérifier qu'il ne nous a pas raconté de bêtises. Fermez cette requête et Enregistrez-là sous R_TransfertEleve. Vous avez vu ? il y a une icône un peu spéciale à côté de votre requête :

Oui. Ca veut donc dire que c'est une requête de type Ajout ?

Mise en garde quant à l'exéction multiple d'une même requête action

Ah oui ! Ca marche ! Et qu'est-ce qui va se passer si je relance ma requête une 2ème fois ?

Je pense qu'il va me remettre les mêmes personnes à la places de celle ci : On ne verra pas la différence ?

FAUX ! C'est une requête AJOUT. Donc il ajoute. Si vous double-cliquez sur votre requête maintenant pour l'exécuter une 2ème fois, vous aurez 30 enregistrements dans T_Employe à la place de 15. Faites-le pour voir. Vous avez maintenant bien 30 employés ?

Oui, comme prévu.

Bon... Hem... On peut résumer ?

Avez-vous bien compris ?

Exercice

Si vous n'êtes pas tout à fait certain d'avoir suivi correctement toutes les étapes de cette leçon, vous avez la possibilité de télécharger ici la version de ProFormation.mdb exactement dans l'état ou elle devrait être à la fin de cette leçon.

Avez-vous une question technique concernant cette leçon ? Cliquez ici !
Une remarque sur cette leçon ? Un problème ? Une erreur ? une ambiguité ? Soyez gentil de m'en informer