Leçon 45 : Nettoyage des tables et recherche d'incohérences : propriété Null Interdit, rappel des modifications de tables, assistant requête Trouver les doublons, assistant requête de non-correspondance, tri des champs mémos, ouverture de fichiers liés par champ OLE

1. Nettoyage du champ "Titre"
2. Nettoyage du champ "NomCelebrite"
3. L'assistant requête "Trouver les doublons"
4. Nettoyage du champ "Prenom"
5. Nettoyage du champ "Domaine"
6. Nettoyage du champ "Pays" et les relations
7. L'assistant requête "Non-Correspondance"
8. Travail de concert avec une table et une requête
9. Rappel de l'intégrité référentielle
10. Nettoyage du champ "EtatCivil", et les exceptions dans les listes déroulantes
11. Nettoyage du champ "Decede"
12. Nettoyage du champ "Salaire", et la différence fondamentale entre Rien et Zéro
13. La propriété Null Interdit
14. Nettoyage du champ "DateNaissance" et les problèmes liés à l'année décrite en 2 chiffres
15. Nettoyage du champ "Remarque", et le tri possible sur un champ Mémo avec Access 2000
16. Nettoyage du champ "Photo", le tri sur les champs OLE, et le double clic sur les objets OLE
17. Nettoyage du champ "DateCreation"

Je ne me rappelle plus comment on fait..

Eh bien, refaites la leçon 19 dans ce cas. Allez, hop hop hop !

OK, ok, c'est bon. Je viens de la relire rapidement. On peut y aller.

Bien. Du premier coup d'oeil, on peut constater qu'il en manque : Les 5 premiers n'ont pas de titre... Pourtant, c'est facile pour les 4 hommes... C'est forcément Monsieur. Par contre pour Chantal Goya, si elle n'était pas connue, on ne pourrait pas dire si c'est Madame ou Mademoiselle. Laissez-là donc en blanc, mais installez les "Monsieur" : . Ensuite, pour continuer à voir ce qui cloche, il suffit de descendre, et de regarder principalement lorsque ça change de titre : , ici, on voit que ça passe de Madame à Mademoiselle, pas de problème.

Encore que.. On ne peut pas être sûr que par exemple Julia Roberts soit vraiment "Mademoiselle"...

Non, c'est un autre genre d'erreur : pour le moment, nous parlons d'erreurs flagrantes de saisie... Pour l'erreur dont vous parlez, il n'y a pas le choix, il va falloir vérifier en téléphonant au client, ou en allant chercher des documents dans les archives... C'est un travail de longue haleine dont nous n'allons pas nous préoccuper.

Un peu plus bas, voyez justement l'une de ces erreurs flagrantes : . Corrigez : . Continuez de dérouler la table, et la dernière erreur est tout en dessous : Mr Charlie Chaplin : Corrigez-le en "Monsieur".

Nettoyage du champ "NomCelebrite"

C'est vraiment plus simple quand les champs sont triés.
On trie les noms de famille maintenant ?

Oui, allez-y.

Déjà, la première personne n'a pas de nom de famille : C'est Loana...

Ce n'est pas très logique... On lui met un nom ?

Vous le connaissez ?

Non...

Moi non plus. Alors on laisse en blanc... On ne va pas inventer des choses qu'on ne connait pas...

Ou alors on écrit "NOM INCONNU" ?

Oui, on pourrait... Bon pour l'instant nous allons le laisser en blanc, car ce simple fait fait que quand on va trier par ordre croissant, les noms en blanc vont apparaître en premier, tandis que si vous écrivez "NOM INCONNU", il va être noyé dans les lettres "N". Et si vous avez encore après quelqu'un dont vous ne connaissez pas le nom, vous allez peut-être oublier qu'il faut écrire "NOM INCONNU", et écrire simplement "INCONNU", et il sera classé, lui dans les "i".

Pas bête. Bon continuons à vérifier ces noms...

Oui, bon on ne peut pas faire grand chose, ça a l'air correct... On peut toujours bien vérifier si tout est bien écrit avec la première lettre en majuscule, et le reste en minuscule, mais ça à l'air d'être le cas... C'est déjà plus difficile à vérifier... Surtout si on avait 5000 personnes à la place de 100 !

Ce que vous pouvez aussi faire, c'est regarder si on a pas interverti le nom et le prénom... Ca n'a pas l'air d'être le cas, bien qu'on puisse avoir des doutes pour les étrangers : "Ingemar Stenmark" par exemple... Si on ne le connait pas, on pourrait se demander si le nom et le prénom n'ont pas été inversés. "Michel Simon" également pourrait être l'objet d'un doute s'il n'était pas connu : Il a un prénom en guise de nom de famille....

Je commence à comprendre les différentes erreurs possibles... C'est donc pour ça que "Opérateur de saisie" est un métier qui demande une certaine rigueur !

Oui : La seule tâche de l'opérateur de saisie est, comme son nom l'indique, de saisir les données... Mais s'il y inclut des erreurs, bonjour le travail de vérification... ça ne vous est jamais arrivé de recevoir le même courrier publicitaire deux fois, en provenance de la même entreprise, simplement parce qu'ils vous ont inscrit 2 fois dans leur programme, avec peut-être une des deux fois ou il y a une petite faute d'orthographe dans votre nom ou dans votre adresse ?

Parfois même, on peut recevoir 2 courriers avec strictement la même orthographe. Ca ne fait pas très sérieux tout de même...

Vous aviez constaté que Francis Cabrel avait été entré 2 fois justement ?

Assisttant requête "Trouver les doublons"

Tiens c'est marrant ça... Mais ce n'est pas facile à repérer, ces doublons, même si les noms sont triés... Il n'y a pas un moyen de les extraire automatiquzement ?

Eh bien si ! C'est une requête en fait . Une requête spéciale qui se crée avec l'assistant "Trouver les doublons". mettons-là en oeuvre.

Marche à suivre :

1. Fermez la table, et demandez justement cette requête: Demandez une requête/Nouveau/Assistant requête trouver les doublons : et cliquez sur OK.
2. Choisissez la table qui pose des problèmes de doublons : c'est T_Celebrite, et cliquez sur Suivant :
3. Cette boîte de dialogue va nous permettre de déterminer quel est le champ qui pose des problèmes de doublons.
   Dans notre cas, c'est le nom de famille pose problème, aussi, faites le passer vers la partie droite avec le bouton > :
   Remarque : Si vous faites glisser plusieurs champs à la place d'un seul, c'est à dire, si par exemple vous faites passer à droite le Nom ET le prénom, alors, la requête va afficher seulement les enregistrements dont le nom ET le prénom sont identiques : Par exemple, s'il y a 2 fois Cabrel Francis, alors, Cabrel Francis va apparaître, par contre si nous avons 2 Hallyday : Johnny et David, ils n'apparaîtront pas, car le prénom est différent. Dans notre cas, nous avons choisi de faire passer seulement le nom sur la droite : la requête va bien entendu nous afficher les deux Cabrel qui ont le même prénom Francis, MAIS AUSSI les 2 Hallyday, même si leur prénom est différent. Imaginons que nous avons une liste de 50'000 clients, et que si on demande seulement le nom, il nous renvoie disons 300 résultats de doublons, la tâche de vérification va être drôlement fastidieuse... Par contre, dans ce cas d'un grand nombre de clients, si on demande le nom ET le prénom, ce n'est plus 300 résultats qu'on va obtenir, mais disons, une vingtaine, ce qui est plus facile à vérifier... Evidemment, si vous aviez des doublons du style Muller Michel, Muller Michell (Le prénom est légèrement différent suite à une erreur de saisie), l'assistant trouver les doublons ne l'affichera pas.
   Cliquez sur Suivant.
4. Ici, vous allez décider des champs que vous voulez afficher pour contrôler vos doublons. Demandez par exemple le prénom, le domaine et le pays d'origine (J'aurai une petite remarque à faire plus bas concernant ces champs*): , et cliquez sur Suivant.
5. Il ne reste plus qu'à nommer la requête : R_CelebriteDoublonNom, et cliquez sur Terminer.

Spectaculaire !

Et le plus génial, c'est que vous pouvez directement modifier les données dans la requête : si vous effacez l'un des deux Francis Cabrel, ça va l'effacer dans la table... Mais bien entendu, il va falloir bien se renseigner : S'agit-il vraiment de la même personne, ou d'un homonyme... ?

Pour Hallyday, c'est plus simple, les prénoms sont radicalement différents...

* Voici la petite remarque que je devais vous faire : Lorsque vous avez choisi les autres champs à afficher (Prénom,. domaine et pays d'origine), vous n'étiez pas obligé d'en mettre. Vous auriez pu n'en choisir aucun. ALors, quand vous ne choisissez rien d'autre que le ou les champs pouvant contenir des doublons, le résultat de la requête s'affiche différemment : Voici le résultat visuel de la même requête, mais ou on a décider de n'afficher QUE le champ nom qui est susceptible de contenir des doublons : . Si vous voulez, vous pouvez essayer. Le problème dans ce cas, c'est qu'on ne peut rien changer dans la requête : On ne peut pas éliminer un des 2 Cabrel... Rappelez-vous bien de ceci, car dans l'exercice qui sera proposé en fin de leçon, c'est ce qui va cous arriver : Vous allez devoir rechercher des doublons dans les tables qui ne comportent qu'un seul champ, ce qui fait que vous verrez un seul exemplaire de chaque enregistrement avec le nombre de doublons à côté.

C'est plus pratique de les voir individuellement quand même :

Dans ce cas, oui. Bon, maintenant, plutôt que d'éliminer sauvagement un des 2 Cabrel de cette requête, fermez-là, et retournez dans la table pour visualiser la ligne complète de ces deux personnes :

Tout laisse à penser que ce sont 2 personnes distinctes : Rien ne correspond... OU ALORS, c'est le même client rentré deux fois avec des erreurs de saisie, OU ENCORE, il y a des renseignements juste dans chacun des deux enregistrements... C'est la confusion totale... Certains renseignements sont peut-être obsolètes...

Et comment peut-on faire pour savoir ce qui est juste de ce qui est faux ?

Access ne peut vous être d'aucun secours ici... C'est du travail administratif, ça. Bon, puisque nous sommes en exercice, et qu'on se doute qu'il n'y a qu'un seul Francis Cabrel, nous allons garder arbitrairement celui qui est dans la chanson. Effacez l'autre (celui qui est "Non-spécifié").

Mais on n'a même pas regardé s'ils étaient correctement orthographiés !

Nettoyage du champ "Prenom"

Ca c'est vraiment un autre boulot ! Trop difficile. Trop long. Encore une fois, on ne s'occupe que des erreurs évidentes dans cette leçon.

Triez par les prénoms maintenant :

Oui, il y en a 5 qui n'ont pas de prénom, mais c'est normal dans ce cas.

Exactement.. Vérifiez la suite, comme pour les noms.

Ils ont bien une majuscule au début, OK, ils me paraissent corrects jusqu'à la fin... Bon il y en a peut être des faux, mais je ne peux pas le savoir, donc, voilà...

Nettoyage du champ "Domaine"

Rien à dire. Passons à la colonne des domaines. Triez-là. On constate tout de suite les incohérences des domaines non spécifiés : . Il y en a des complètement vides, des ?? et des ???.. Et lorsqu'on va demander un état regroupé sur le domaine, il va créer un groupe avec les vides, un groupe avec les ?? et un groupe avec le ???... NUL !

Qu'est-ce qu'on fait alors ? on met tout à blanc ?

On pourrait... C'est d'ailleurs ce qu'on a fait jusque-là, par exemple avec les titres... Bon, moi, je pense que ce serait plus judicieux de mettre "Non-spécifié" en toutes lettres, ce qui me parait plus clair... Mais ce choix "Non-spécifié n'apparaît pas dans la liste déroulante... On pourrait l'y ajouter si vous allez en mode création. Vous vous souvenez comment on fait ? C'était à la leçon 14. Rappel :

1. Allez en mode création de la table T_Celebrite
2. Sélectionnez le champ Domaine
3. Dans les propriétés, cliquez sur l'onglet "Liste de choix" :
4. Clqiuez dans la zone de contenu :
5. Appuyez sur la touche END de votre clavier pour être à la fin de la liste :
6. Ajoutez très exactement cet élément sans oublier le point virgule ni les guillemets : ;"Non-spécifié"

Lancez la table en mode saisie de données, et Enregistrez-là : Vous pouvez maintenant sélectionner Non-spécifié pour tous ceux qui étaient blancs ou avec des ??? :

Ou alors, on aurait pu les mettre en "Divers" ?

C'est discutable... Disons que pour respecter le fait que la personne qui a fait la saisie n'a pas spécifié "Divers", nous allons entrer la nouvelle catégorie "Non-spécifié", tout simplement.

D'ailleurs, pour éviter la tentation de laisser le champ vide, faisons deux choses :

1. Interdire de laisser le champ vide (Propriété Null Interdit : Oui)
2. Valeur par défaut : "Non-Spécifié" (en toutes lettres donc)

Comme ça, d'entrée, la personne qui effectue la saisie verra "Non-spécifié" dans le domaine d'une nouvelle célébrité qu'elle entrerait, et si elle essaie de l'effacer, Access renverra un message d'erreur. C'est du béton !!!

La valeur par défaut, nous avons vu ça à la leçon 38 (), et pour empêcher de laisser un champ vide c'est facile : Null Interdit : . Quand vous allez relancer la table en mode saisie de données, comme tout à coups vous supprimez le fait que des colonnes puissent être vides, Access va vous prévenir que "Les règles d'intégrité des données ont été modifiées, gna gna gna", dites simplement OK, et acceptez qu'il teste des nouvelles règles.

Un peu plus bas, il y a ceux qui font du cinéma, rien à signaler...

Oh que si il y a quelque chose à signaler ! Tommy Lee Jones et Bruce Willis font du CinEma, sans accent !

Même ça, ça compte ?

Absolument ! Si vous demandez un état groupé par Domaine, Access va vous créer un groupe de Cinéma et un groupe de Cinema... Donc, vous me remplacez ces deux Cinema par Cinéma.

Mais il n'y avait pas un truc pour justement empêcher d'écrire autre chose que ce qui se trouve dans la liste déroulante ?

Mais oui ! Cétait expliqué a peu près au milieu de la leçon 14. Mettez dont la propriété "Limiter à liste" à Oui de "Domaine". Mais encore une fois, c'est seulement à partir de maintenant que l'on ne peut plus choisir autre chose que ce qui est proposé.

Un peu plus bas, nous avons les "Divers", et les "Non-spécifié". C'est vrai que c'est ce que nous voulions, mais finalement, à y regarder de plus près, c'est vraiment idiot d'avoir deux catégories aussi proches... Allez, on garde "Non-spécifié", et on élimine "Divers". Marche à suivre :

1. Dites que chaque "Divers" est en réalité "Non-spécifié" : . Soit vous le faites un par un, à la main, soit, vous utilisez la fonction "Remplacer" (Leçon 19)
2. Eliminez de la liste de choix "Divers" : . La liste est désormais : "Affaire";"Chanson";"Cinéma";"Politique";"Sport";"Télévision";"Non-spécifié"

Le reste va bien. Il y a juste la dernière : Martina Hingis qui est en "Tennis".
Je la transforme en "Sport".

Nettoyage du champ "Pays" et ses relations avec la table T_Pays

Triez maintenant la colonne des Pays. Ca devrait éveiller en vous de vieux souvenirs... C'était aux leçons 16 et 17 : Les relations !

Avant d'aller plus loin, je vous conseille très vivement de les réviser, car si vous avez oublié de quoi il s'agit, vous aurez de la peine à continuer cette leçon.

Je me suis rafraîchit l'esprit : Les relations simples, avec intégrité référentielle, la clé primaire obligatoire, les options de mettre à jour et effacer en cascade, je me souviens de tout maintenant.

Parfait. Fermez la table T_Celebrite, et allez dans les relations. Y a-t-il une relation entre T_Pays et T_Celebrite ?

Oui, mais il n'y a pas d'intégrité référentielle, ce qui veut dire a peu près que c'est comme il n'y avait pas de relation du tout, quoi...

Vous arrivez à mettre l'intégrité référentielle entre ces deux tables ?

Non, ce serait trop beau.. Il me dit que les données ne correspondent pas...

Bien sûr, il y a plein de personnes qui sont originaires de pays qui n'existent pas dans T_Pays... Mais lesquels ?

C'est un beau désordre... Dans T_Pays j'ai seulement Belgique, France, Italie et USA, mais alors dans T_Celebrite... J'ai des Allemagne, des Angleterre, des Etats-Unis, des Suisse, des U.S.A. C'est vraiment pas évident...

Et encore, là on a que 100 personnes !

Il y a une possibilité de voir instantanément ceux qui ne correspondent pas ?

L'assistant requête de Non-correspondance

OUI ! Access à dans son sac à malices un super outil, qui s'appelle la "Requête de non-correspondance".

Mettons-là en oeuvre : nous voulons donc visualiser les célébrités qui sont originaire d'un pays qui n'existe pas dans T_Pays. Fermez les relations et toutes les tables que vous auriez pu ouvrir :

1. Cliquez dans Requête/Nouveau/Assistant requête de non-correspondance, et OK :
2. Comme c'est dans T_Celebrite que nous désirons voir les problèmes, sélectionnez T_Celebrite, et cliquez sur Suivant :
3. Sélectionnez maintenant l'autre table qui est en relation avec T_Celebrite pour laquelle il va falloir vérifier les pays... Bon, on n'a de toute façon pas le choix, c'est la seule autre table : T_Pays : , et cliquez sur Suivant.
4. A pèrésent, il faut l'informer quel champ de quelles tables doivent être mis en correspondance.
   Access a bien compris que c'est PaysOrigine de T_Celebrite qui doit être comparé à Pays de T_Pays, parce qu'il a bien écrit PaysOrigine <==> Pays. . il a bien compris ça parce qu'il y a une relation existante entre les deux tables (Sans intégrité référentielle, certes... mais une relation quand même). Si il n'avait pas compris quels champs il fallait comparer il aurait suffit de cliquer dans PaysOrigine à gauche, Pays à droite, et cliquer sur le bouton <==>. Cliquez sur Suivant.
5. Choisissez maintenant quels champs vous souhaitez visualiser dans cette requête de non-correspondance : Envoyez à droite les champs Prénom, NomClient, et, bien entendu PaysOrigine qui est le plus important :
6. Appelez votre requête R_CelebritePaysFantaisiste, , et comme il n'y a plus de bouton Suivant, cliquez sur Terminer.

Vous vous retrouvez avec 48 enregistrements à problèmes :

Quand même ! Quel travail en perspective !

Nettoyage du champ "Titre"

Pas tant que ça en fait, car si vous regardez de plus près, il y en a toute une quantité qui ont pour origine "Etats-Unis".

1. Fermez la requête
2. Ouvrez la table T_Pays
3. Ajoutez comme pays : Etats-Unis (Vous aurez USA et aussi Etats-Unis, ce n'est pas grave)
4. Fermez T_Pays
5. Rouvrez la requête R_CelebritePaysFantaisiste

C'est mieux ! Maintenant on n'a plus que 22 enregistrements

C'est vraiment plus facile à gérer ! Partons à la chasse aux fautes d'orthographe : Bourvil vient de France, pas de Frence. Corrigez-le directement dans la requête.

Julia Roberts ne vient pas de Francce, mais de France.
MAIS ! même pas ! Elle vient des Etats-Unis en fait, non ???

Parce que vous la connaissez ! Mais si c'était une parfaite inconnue, vous n'auriez pas pu le savoir ! Allez, mettez-lui Etats-Unis.

Et Tom Selleck, on va dire qu'il vient des Etats-Unis à la place de U.S.A, car sinon, on va avoir 2 dénominations pour un même pays, c'est nul !

Si vous fermez la requête à ce stade et que vous la relancez, vous avez ceci :

C'est juste.

Maintenant, il y a des gens qui proviennent d'Angleterre et du RoyaumeUni... Moi je dirais que tout le monde vient de Grande-Bretagne, et puis c'est tout.

1. Fermez la requête
2. Ouvrez T_Pays
3. Ajoutez Grande-Bretagne à la liste
4. Fermez T_Pays
5. Rouvrez la requête R_CelebritePaysFantaisiste
6. Remplacez tous les Royaume-Uni et Angleterre par Grande-Bretagne :

Pour les pays qui restent, qu'est-ce qu'on fait ?

Nous allons tout simplement ajuster la fenêtre de la requête en taille intermédiaire (je pense que vous savez faire ça, c'est Windows...), et ouvrir la table T_Pays pour l'installer à côté, comme ceci :

Ah, oui, ça na rien a voir avec Access, c'est simplement placer deux fenêtres côte à côte !

Comme la requête contient tous les gens dont le pays n'apparait pas dans T_Pays, il suffit de les ajouter à la main, comme ceci (Un seul exemplaire de chaque pays dans T_Pays bien sûr):

Fermez ensuite la requête et rouvrez-la immédiatement après : . Il ne reste plus que les gens dont le pays d'origine est inconnu.

On ajoute "Non-Spécifié" dans la table des Pays ?

On pourrait, mais on va laisser comme ça cette fois.

Dernière chose, dans T_Pays, supprimez USA, puisque maintenant, c'est Etats-Unis qu'il faut choisir pour les américains : Et ATTENTION : Parce qu'en supprimant USA de la liste des pays, il y avait peut être une célébrité pour laquelle le pays d'origine est USA. Relancez la requête R_CelebritePaysFantaisiste.

Vous aviez raison ! Il y a Walt Disney qui était originaire des USA !

Remplacez-le par Etats-Unis :

Il faut vraiment penser à tout !

Comme je l'ai répété à maintes reprises, il est indispensable, quand vous concevez une base de données, de faire en sorte que la saisie soit la plus propre possible

Rappel de la notion d'intégrité référentielle

Je suppose qu'on peut établir l'intégrité référentielle entre T_Celebrite et T_Pays ?

Allez y ! Fermez toutes les tables et les requêtes encore peut-être ouvertes, et allez dans outils/Relations :

On coche les options de mise à jour et d'effacement en cascade ?

Mmmhhh... Cochez juste l'option de mise à jour.

C'est fini pour les pays ?

Oui, maintenant, ça va aller plus vite, car vous avez sans doute bien compris la philosophie du nettoyage.

Nettoyage du champ "EtatCivil" et les exceptions dans une liste déroulante

Retournez dans T_Celebrite, et triez par la colonne des Etats Civils. Vous avez repéré ce qui cloche ?

Facile. Les points d'interrogation que j'efface, Vincent Lagaf que je met à Marié(e) au lieu de Marié, Et Julia Robert que je change à Divorcé(e), c'est ça ?

Tout juste SAUF Julia Roberts. Elle est Séparée, elle n'est PAS divorcée, ce n'est pas pareil. Soit vous laissez tout comme ça, et vous acceptez que l'on puisse entrer autre chose que ce qu'il y a dans la liste (Limiter à Liste : Non), ou alors, vous ajoutez dans la liste "Séparé(e)"

Dur choix... Laissons comme ça, c'est tellement rare, l'état Civil "Séparé(e)"

OK. Vous avez vu les avantages et les inconvénients dans la leçon 14.

Nettoyage du champ "Decede"

Triez maintenant par Décédé

Rien à dire : C'est oui ou c'est non, on ne va pas vérifier si les gens décédés le sont vraiment, donc, on laisse comme ça.

Nettoyage du champ "Salaire" et explications de la différence entre Rien et 0

OK. Triez par Salaire

Bon, ben pareil, on ne va pas vérifier leur validité...

On va surtout regarder s'il n'y a pas de salaire qui sont visiblement extravagants : personne ne gagne 2 francs, ou un milliard ?

Non, soit c'est 0, soit ça va de 2'284 à 30'000, c'est cohérent.

Il y a juste un petit truc qui me chiffonne, c'est qu'on peut carrément effacer un salaire, comme ceci : . C'est un peu ennuyeux, rien que dans les requêtes, car si on demande les salaires égaux à 0, on aura pas ceux qui sont Nuls (à Blanc)... C'est vraiment dangereux.

La propriété Null Interdit

En mode création, je vais définir Null Interdit : Oui

Oui, comme ça, on ne pourra pas effacer le champ complètement. En plus, nous allons définir la valeur par défaut à 0:. Essayez maintenant d'effacer un salaire

Ca ne marche pas :

Exactement, ce charabia à moitié en français à moitié en anglais (Merci les traducteurs Microsoft !) Veut dire que vous ne pouvez pas complètement effacer ce champ.

On a fini avec le salaire ?

Nettoyage du champ "DateNaissance" et description des problèmes liés à l'année décrite sur 2 chiffres

Oui. Triez par date de naissance.

Qu'est-ce qu'on regarde cette fois ?

Les plus anciennes et les plus récentes, simplement... Il y a des années de naissances un peu douteuses : 1780, 1878, 1879...

Mais c'est normal, c'est Napoléon, Sacha Guitry et Wal Disney

Effectivement. Mais les plus récentes, par contre...

Y'a un problème : .. Ils sont pas encore nés ceux là !

Les erreurs de saisie peuvent très bien provenir de l'année sur 2 chiffres... Vous sous rappelez, on en a parlé à la leçon 7 ?

Oui, je viens d'aller voir, c'est fort possible.

On ne va pas se casser la tête, on va vieillir ces 3 personnes de 100 ans :

OK. Encore que je ne pense pas que Cathy Zeta-Jones soit vraiment si agée...

Je vais vous faire un aveu, toutes les dates de naissances sont fausses...Elles sont simplement vraissemblables pour la plupart...

C'est vraiment un nettoyage en très gros...

C'est le travail du concepteur Access, laissons aux opérateurs de saisie de soin de corriger les erreurs "Humaines"

Nettoyage du champ "Remarque" et le tri possible sur un champ Mémo dès Access 2000

On trie par Remarque maintenant ?

Essayez seulement pour voir !

C'est juste, on ne peut pas, parce que c'est un champ Mémo, on a vu ça dans la leçon 6 ! C'est une sacrée récapitulation cette leçon !

C'était le but. Par contre, bonne nouvelle pour les utilisateurs d'Access 2000 et XP, mais pas pour Access 97... Avec Access 2000 et XP, vous pouvez créer une requête en demandant un tri croissant sur la remarque. Essayez : Mettez le nom, le prénom et la remarque, et triez par la remarque : . Lancez la requête. Quelque chose à signaler ?

Non pas vraiment...

On ne va donc rien changer. Les utilisateurs d'Access 97 peuvent respirer. Vous pouvez fermer cette requête et l'enregistrer sous R_CelebriteTriRemarque, avec comme description de la requête : Access 2000 seulement (Leçon 12 pour ceux qui ont oublié comment on appose une description).

Nettoyage du champ "Photo", le tri sur les champs OLE et l'activation d'un champ OLE

On trie par Photo ?

Non, parce que ça, c'est carrément impossible, quelle que soit la version d'Access (Essayez pour voir le genre de message d'erreur que vous avez). Par contre, pour se rendre compte des différents objets qui ont été intégrés dans ce champ, vous pouvez créer une requête basée sur T_Celebrite, avec le nom, le prénom, et Photo, et demander les Photo Pas Null : , ce qui va permettre de voir les 2 seuls enregistrements qui ont quelque chose à montrer. Vous pouvez même double-cliquer sur les éléments insérés pour les visualiser : , Dans le cas d'une image, c'est le logiciel Photo Editor qui va ouvrir l'image (normalement) : , et bien entendu, si vous cliquez deux fois sur un document Word, c'est Word qui va ouvrir le document, s'il n'y a pas de problème de configuration sur votre PC. (Je dis ça parce qu'il peut survenir fréquemment des problèmes de style , et dans ce cas, si tout se passe bien, il suffit de répondre oui pour que tout rentre dans l'ordre, et dans le cas contraire, il vous faudra peut-être réinstaller Office sur votre PC... Désolé, c'est comme ça, c'est la vie sous Windows !)

Enregistrez cette requête sous R_CelebriteAvecPhoto.

Nettoyage du champ "DateCreation"

Il ne reste finalement plus que le champ Date de création... le tri ne montre rien d'intéressant, il n'y a qu'une personne avec une date de création, c'est Albert Einstein

On ne peut pas faire grand chose ici. On pourrait, si on voulait, remplacer toutes les dates vides par par exemple "01.01.1980 00:00", histoire d'éviter les blancs, mais d'une part ça n'avancerait pas énormément le Schmilblick, et, d'autre part, ça demanderait l'explication d'une requête particulière, qui est la requête de mise à jour, que nous n'allons pas voir ici, cette leçon étant suffisamment longue comme ça.

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