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
. 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 :- Allez dans F_EleveSF en mode création (Bouton droit de la souris sur F_EleveSF, et Mode création)
- Demandez les propriétés du formulaire
- Dans la propriété Source, choisissez T_CoursDetail :
Pendant qu'on y est, pourrait-on renommer F_EleveSF en F_CoursDetailSF ?
Oui. Quels sont les problèmes que vous pensez pouvoir surgir si on fait ça ?Mmmmh... Peut-être que le formulaire principal F_Cours ne reconnaîtra plus le sous-formulaire ?
Essayons :- Renommez F_EleveSF en F_CoursDetailSF
- Lancez F_Cours.
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) :
- Allez en mode création de F_Cours
- Demandez les propriétés de la zone d'accueil du sous formulaire (le grand rectangle blanc donc)
- Dans l'onglet Données, précisez que l'objet source est F_CoursDetailSF :
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.
Vous avez une idée de ce qu'elle va contenir comme champs, cette table ?
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).Il y a une clé primaire dans cette table ? (Leçon 13)
Je ne crois pas non ...
Eh bien nous allons en mettre une. Vous savez pourquoi ?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 !!!
BRAVO ! C'est ça. Rien à redire.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é :AVANT de choisir Requête Ajout :
APRES avoir choisi la requête Ajout :
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...
J'Y ai pensé ! Mais je l'ai fait exprès !!! HA HA HA !!!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 ?
Oui. C'est ça. Allez dans la table T_Employe :
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 ?
Qu'est ce que vous en pensez ?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.
Bien nous allons nous arrêter là pour cette leçon.
Bon... Hem... On peut résumer ?
| Dans cette leçon, nous avons constaté au début que le changement du nom de tables ou de formulaires pouvait avoir de fâcheuses incidences sur le bon fonctionnement de la base de données en général. Ensuite, nous avons apprécié l'uutilité d'une requête action : La requête Ajout. C'est une requête "action" par opposition à une requête de visualisation qui permet comme son nom l'indique de visualiser les données (toutes les requêtes que nous avons étudié jusque là en étaient). La requête de type Action effectue des modifications dans les tables. Nous verrons plus tard qu'il existe d'autres actions possibles dans les requêtes. |
Avez-vous bien compris ?
|
Exercice
| Téléchargez cette base de données. Vous y trouverez ces 2 tables : T_ObjetDivers, qui contient 10 objets, dont 6 sont de type informatique :  T_AccessoireInformatique, qui contient 3 articles informatiques :  L'exercice consiste, à l'aide d'une requête Ajout que vous nommerez R_CompleteInformatique, à copier les 5 objets de type informatique dans T_AccessoireInformatique. Voici T_AccessoireInformatique après la copie :  Visualisez la solution de l'exercice ici |
0 commentaires:
Enregistrer un commentaire