Sommaire
- Le type de données Numérique et les erreurs de conversion
- Le type de données Numérique/Réel Simple
- Le type de données Numérique/Entier Long
- La propriété "Légende"
- La propriété "Valide Si"
- La propriété "Message Si Erreur"
- Les mots clés Entre ... Et ...
- QCM
- Exercice
Quelle est l'utilité de la liste
?
Cette liste contient les différents types de données. Chacun de ces types correspond à un genre d'information. Par exemple, si on veut insérer la date de naissance des clients, on va choisir un type de données "Date/Heure".
Oui, mais j'ai constaté que les champs NomClient et Prenom sont en type Texte, et je peux mettre du texte ou des chiffres, ou n'importe quoi. Alors pourquoi est-ce que je choisirais autre chose ?
Justement pour éviter d'écrire n'importe quoi. Admettons qu'on veuille entrer la taille des clients. Si vous créez un champ "Taille" et que vous le laissez en texte, vous aurez la possibilité d'écrire n'importe quoi dedans. Faisons le test.Créez un champ Taille :
Lancez la table en mode saisie de données :
Complétez-là comme ceci :
Vous constatez qu'à cause du fait que le champ Taille est en Texte, on peut y écrire des mesures tout à fait fantaisistes ! Pour l'instant, c'est un peu égal, mais admettons qu'il s'agisse d'une longue liste de trois mille basketteurs, et qu'il s'agit de les trier en ordre croissant de taille, vous imaginez bien que ça va être mission impossible !
Il s'agit donc d'empêcher celà. Revenez en mode création.
Le type de données Numérique et les erreurs de conversion
Définissez le champ Taille comme étant numérique :
Lancez la table en mode saisie de données. Access vous demande d'enregistrer la table. Dites Oui. Ensuite, il vous affiche ce message :
Le 1M68 est "Presque" numérique, mais il suffit d'une seule lettre (M) pour que le champ soit définitivement considéré comme du TEXTE !
Répondez OUI à ce message d'avertissement. Vous vous retrouvez alors avec votre table dans cet état :
Avant la conversion de texte en numérique :
Après la conversion de texte en numérique (Maintenant) :
Nous constations plusieurs choses :
- Les enregistrements ne sont plus dans le même ordre (Bill Clunton est maintenant en première position). Il arrive parfois à Access de réagencer l'ordre des enregistrements. Ceci n'est pas grave du tout en ce sens qu'on va de toute façon pouvoir trier les tables dans n'importe quel ordre un peu plus tard - Il se peut même que chez vous, l'ordre ne soit pas le même qu'ici. Ne me demandez pas pourquoi, je n'en sais rien...
- Bill Clunton et Michael Jordin n'ont maintenant plus de taille... Access nous avait bien prévenu qu'il allait faire ça ! Si nous avions eu 16'500 clients qui avaient une taille contenant du texte, Access les aurait effacées tout pareil ! Attention donc.
- Jean-Paul Brulmondo ne mesure PAS 2 mètres ! Mais Access ne supporte pas les décimales. Pour qu'il les accepte, c'est une option que nous allons voir un peu plus tard. Si Nous avions dit que Jean-Paul Brulmondo faisait 1.49, alors Access l'aurait ramené à 1 (Arrondissement au nombre entier le plus proche)
- Access à ajouté 0 pour un nouveau client qui n'existe pas : C'est une valeur par défaut installée par Access lorsqu'on demande du numérique. Nous verrons les valeurs par défaut un peu plus tard.
J'ai tout compris, mais c'est quand même drôlement gênant cette histoire de décimales qui n'exisitent pas ! Comment peut-on les mettre ?
Nous allons voir ça. Revenez en mode création de la table. Cliquez sur le champ taille
. Vers le bas de votre écran, vous constatez qu'il y a toute une série d'options. Ce sont les options de champ :
.Le type de données Numérique/Réel Simple
C'est dans ces options que nous allons fouiller pour trouver l'endroit ou nous allons pouvoir préciser comment faire pour que la taille accepte les décimales. C'est la propriété (l'option) Taille du champ qui nous intéresse. Cliquez dans taille du champ. Une petite flèche apparaît à droite. Cliquez dessus et choisissez "Réel Simple" à la place de "Entier Long" :
Une fois ceci fait, retournez dans la table en mode saisie de données. Vous constatez que rien n'a changé... Notamment Jean-Paul fait toujours 2 mètres.. Donc le 1.86 a été définitivement changé en 2 (Contrairement à Excel qui garde en mémoire les vraies valeurs, mêmes si vous les arrondissez).
PAR CONTRE... MAINTENANT vous POUVEZ mettre 1.86 comme taille à Jean-Paul : Il va le garder. Faites le :
. Même si vous revenez en mode création, ou que vous quittez Access. 1.86 va pouvoir être stocké.Comment cela se fait-il ? Et c'est quoi toutes ces options : Octet, Entier, etc...
Nous sommes ici en contact avec le fonctionnement interne des ordinateurs. Il n'est pas nécessaire de s'étendre sur les différents types de numériques. Pour l'instant, il vous suffit de retenir que si vous avez besoin de chiffres avec des virgules, vous choisissez un numérique de type Réel SImple. Si vous n'en voulez pas, vous choisissez Entier Long. Il y a des exemples ou on ne veut pas de virgules : Par exemple un champ qui s'appellerait AnneeNaissance (Pas Date de naissance, juste l'année) : Là on ne veut PAS de décimales. Ou encore si vous avez une table de voitures qui recense des voitures d'occasion à vendre, un hypothétique champ Poids ne devrait pas comporter non plus de décimalesDonc, dans notre cas, on veut des décimales ou pas finalement ? Parce que ça dépend : Si on compte la taille en centimètres par exemple ?
Excellente remarque ! Effectivement. Complétez votre table comme ceci :
Vous constatez qu'il y a un hic : En effet, certaines tailles sont exprimées en mètres (1.63 , 1.86), et d'autres sont exprimées en centimètres (210 et 177). Vous imaginez bien que lorsqu'il va s'agir de trier les clients par taille, ça va très mal se passer... Ils seront classés comme ceci : 1.63, 1.86, 177 et 210...
Il s'agit donc d'être très vigilant dès la création de la base de données, des tables et des champs avant de penser à entrer des données, sinon... vous courez à la catastrophe.
Peut-on faire quelque chose pour éviter celà ?
Oui, bien sûr. Déjà, le simple fait d'avoir mis le champ Taille en numérique plutôt qu'en texte évite déjà bien des malheurs puisque vous ne pouvez absolument pas entrer le moindre texte. Nous allons essayer ça. Lancez la table en mode saisie de données, et essayez d'écrire ceci :
. Access accepte, mais essayez maintenant de cliquer sur un autre client (Michael Jordin par exemple). C'est ici que ça se gâte. Vous obtenez ce message d'erreur : 
. Il veut bien dire ce qu'il veut dire : Vous n'avez PAS le droit de mettre autre chose que du chiffre dans cette zone ! Cliquez sur OK.Il vous a laissé votre texte, mais il va refuser obstinément de vous le valider. Vous ne pouvez même plus revenir en mode création. Access vous prend en "Otage" tant que vous ne remédiez pas à cette situation. Vous avez deux solutions :
- Vous écrivez une taille qui ne contient que du chiffre
- Vous appuyez sur la touche ESC
pour éliminer ce que vous avez écrit.
Le type de données Numérique/Entier Long
Oui, d'accord, mais comme vous avez dit, ça n'empêche pas de mélanger les tailles en mètres et en centimètres !
Effectivement. Bon, admettons que pour normaliser, nous décidions que tous les clients doivent avoir leur taille exprimée en centimètres ! Une arme que vous connaissez déjà est de définir le champ Taille en numérique ENTIER LONG au lieu de réel simple. Faites le changement maintenant, c'est à dire définissez le champ Taille en numérique ENTIER LONG. Lancez la table en mode saisie de données. Il vous demande de l'enregistrer, dites oui, et... Oh oh... Ce message apparaît :
En gros, il est en train de nous annoncer que :
"Hè ! Attention ! Vous me demandez de changer une option d'un champ numérique, mais faites gaffe ! Maintenant, je ne vais plus pouvoir vous afficher les décimales ! Oui, je sais que c'est bien ce que vous voulez, mais il peut très bien y avoir des tailles qui ONT des décimales ! Je vais être obligé de les arrondir ! Et vous ne pourrez plus revenir en arrière ! C'est vraiment ça que vous voulez ?"
Dites Oui.
Avant, notre table ressemblait à ça :
Et maintenant, elle ressemble à ça :
Eh oui ! Access nous avait prévenu ! 1.63 et 1.86 ont été arrondi à 2... Bon là nous n'avons que 4 clients, ça va ! Mais si on en avait eu trente mille... Il aurait tout bousillé ! Nous nous retrouvons à notre situaition du tout début ou on ne peut plus entrer de décimales. Il ne vous reste plus qu'à corriger à la main. Allez-y : 
C'est vrai que c'est un bon point, mais tout ceci n'empêche pas de mettre indifféremment 2 ou 200 pour Michael Jordin ...
La propriété "Légende"
C'est vrai. Ce qu'on pourrait faire, c'est remplacer le champ "Taille" par "Taille (CM)", ce qui nous permettrait d'avoir, en haut de la colonne, une indication... Mais, comme je l'avais souligné lors d'une leçon précédente, il vaut mieux vraiment éviter les noms de champs avec des espaces, des parenthèses, etc. Alors, Microsoft à eu l'excellente idée de donner une option de champ qui s'appelle légende (en bas de votre écran en mode création, un peu plus bas que "Taille du champ" que nous avons déjà vu) :
Cette option permet de dire ce qu'on a envie qui soit indiqueé en haut de la colonne à la place du champ. S'il n'y a rien d'indiqué dans cette propriété Légende, alors, c'est le nom du champ qui est écrit.
Ecrivez Taille (CM) dans la propriété Légende du champ Taille :
, et lancez la table en mode saisie de données. Vous constatez que maintenant l'en-tête de colonne est 
Ca, c'est une première chose. On peut également donner une description du champ plus approfondie. Revenez en mode création. Nous allons nous intéresser à la zone "Description" :
Cette zone permet de décrire le champ avec encore plus de détails que la légende. Ecrivez-y : "La taille est exprimée en centimètres" :
. Ce texte apparait en mode création, mais également en mode saisie de données, dans la barre d'état, c'est à dire tout en bas de votre écran. Malheureusement, cette information va apparaître de manière trop discrète. Lancez la table en mode saisie de données, er regardez tout en bas de votre écran. Vous devriez voir ce texte : 
. Cliquez dans une taille (n'importe laquelle), et remarquez que le texte dans la barre d'état a changé : 
.La propriété "Valide Si"
C'est de mieux en mieux. Cette fois, il faut vraiment le faire exprès pour se tromper. Je vais peut-être paraître insistant, mais peut-on carrément INTERDIRE d'écrire des tailles en mètres ?
Oui. C'est possible. Grâce à la propriété "Valide si" :
. Cette propriété va nous permettre d'interdire purement et simplement toute valeur inférieure à 140 ! Comme ça, si on essaie d'écrire 1.85 par exemple, Access va le refuser car 1.85 est simplement inférieur à 140. L'utilisateur devra écrire plutôt 185.Avant d'utiliser cette propriété, nous allons d'abord, exprès, installer une valeur erronnée pour l'un des clients. Lancez la table en mode saisie de données, et précisez qu'Alain Dalon Mesure "2" à la place de 177 :
. Cette opération vise à bien comprendre comment Access va se comporter alors que nous allons justement maintenant INTERDIRE les valeurs inférieures à 140. Revenez en mode création.Mettez ">=140" (">=" veut dire "Plus grand ou égal à") dans la zone Valide si :
Essayons. Lancez la table en mode saisie de données. Access demande d'enregistrer la table, acceptez, et ... Suprise : Vous avez ce message :
Répondez Oui à cette question. Le fait de répondre Oui va vous interdire A PARTIR DE MAINTENANT d'entrer des tailles inférieures à 140. Mais les tailles qui existaient déjà et qui étaient inférieures à 140 restent en place. Il faudra les corriger à la main. C'est différent du début de la leçon, quand nous avons transformé le champ "Taille" qui était Texte en Numérique. Dans ce cas là, c'était sans appel ! Les tailles qui contenaient du textes étaient purement et simplement effacées !
Ici, c'est plus subtil. Les valeurs restent, mais... c'est quand même un problème, ces tailles en mètres qui subsistent : Il faudra les corriger manuellement. Et s'il y en a 4000 à corriger, ce n'est plus drôle. C'est pourquoi, je répète qu'avec Access, avant de foncer tête baissée, il est nécessaire de régler tous les paramètres en connaissance de cause AVANT d'entrer des grosses masses de données !
Allez dans la taille de Michael Jordin, et essayer de lui attribuer une taille de 2.10 :
. Tout se passe bien, mais allez sur un autre enregistrement, c'est ici que ça se gâte. Vous obtenez ce message d'erreur :
).Bon. C'est parfait. Mais il y a une chose qui me gêne un peu : Ce message : "Une ou plusieurs valeurs sont interdites par la règle de validation, gna gna gna", c'est parfaitement incompréhensible ! Si ce n'est pas moi qui entre les données et que la personne tombe sur ce message, elle ne va rien comprendre !
La propriété "Message Si Erreur"
C'est vrai! Heureusement, il y a une parade : On a la possibilité de remplacer ce message épouvantable par un message personnalisé. Cette propriété s'appelle "Message si erreur". Revenez en mode création, cliquez sur le champ Taille, et regardez les options en bas :
. Dans Message Si Erreur, écrivez : "J'ai dit que la taille devait s'exprimer en CM !!!" : 
.Lancez la table en mode saisie de données, et essayez de changer la taille de Michael Jordin en 2.23. cliquez sur quelqu'un d'autre. le message d'erreur survient :
. Qui est beacoup plus explicite. Ne cliquez surtout pas sur Aide, vous allez vous retrouver dans l'inextricables explications qui n'ont pas grand chose à voir avec notre taille. Cliquez sur OK, et appuyez sur pour revenir à la taille d'avant.Voilà ! c'est exactement ça que je voulais ! Maintenant, les erreurs sont vraiment limitées ! Mais par contre, je suis en train de penser à un truc, comme on peut mettre n'importe quoi de supérieur à 140, je peux me tromper et dire qu'un client mesure 1850 centimètres au lieu de 185... On peut faire quelque chose aussi contre ça, docteur ?
Oui, ce n'est pas bien compliqué. On pourrait imaginer qu'on refuse toute valeur inférieure à 140, mais aussi toute valeur supérieure à 220. Bon ça suppose qu'on ne peut pas avoir de clients de moins d'un mètre quarante ni plus grand que deux mètres vingt, mais vous pouvez ajuster les valeurs.Les mots clés Entre ... Et ...
En mode création de votre table : Mettez simplement "Entre 140 et 220" dans la zone Valide Si :
. Maintenant, vous commencez à comprendre la manoeuvre : Vous allez en mode saisie de données, vous essayez d'entrer une valeur pour un client qui est supérieure à 220, et vous allez constater que votre message d'erreur s'affiche. Après avoir testé, revenez en mode création.Ah oui ! Là. je suis vraiment satisfait. Mais encore une petite chose, si je ne connais pas la taille du client, j'aimerais bien la laisser à 0... Mais 0, c'est plus petit que 140, il va me refuser, non ?
C'est clair qu'il va refuser ! Il faut tenir en compte ce cas de figure ! Si vous laissez les choses comme ça, vous allez être obligé de mettre une taille à chaque nouveau client, et comme vous ne connaîtrez peut-être pas la taille de vos nouveaux clients, vous allez devoir leur inventer une taille fictive ! C'est nul, évidemment !Pour contourner ce problème, vous allez simplement mettre ceci dans la zone Valide Si : 0 Ou Entre 140 Et 220 :
. Vous pouvez tester : Vous allez pouvoir entrer 0, ou une valeur comprise entre 140 et 220, mais tout le reste sera impitoyablement refusé.Maintenant, tout est parfait... Je ne vois pas comment on pourrait encore se tromper !
Si vous buvez un litre de whisky avant de commencer votre saisie, je suis sûr que vous arriverez bien à faire des erreurs ;-)Oui, évidemment ! Bon, ceci dit, la taille des clients, on s'en fiche un peu, non ?
Oui mais c'est pour bien illustrer les notions de champ et d'options de champs. Nous allons nous arrêter là. Vous pouvez fermer votre base de données.
Bon... Hem... On peut résumer ?
Chaque table est pourvue d'un certrain nombre de champs. Chacun de ces champs est d'un type particulier (Texte, Numérique, Date) selon le genre de chose qu'il va contenie. Un champ Taille va être numérique. Un champ Téléphone va être Texte (Et oui : Un numéro de téléphone peut contenir des points, les parethèses, des espaces...). Ces champs ont certaine options :
|
Avez-vous bien compris ?
|
Exercice
| Créez une base de données que vous appellerez matrimo.mdb. C'est une agence matrimoniale. Vous y créerez une table T_Candidat, qui sera sensée contenir tous les candidats qui cherchent l'âme soeur. Vous y créerez un champ NomCandidat, et un champ Prenom, qui seront évidemment en texte. Bien que ces champs s'appellent NomCandidat et Prenom, en mode saisie de données, il faut voir comme en-tête de colonne "Nom" et "Prénom" (Sans les guillemets - avec un accent). Vous y créerez également un champ Age que vous définirez avec le bon type de données. Il faudra refuser les ages inférieurs à 18 et supérieurs à 100. Il faudra en outre accepter les ages inconnus (les valeur 0). Dans le cas ou on essaie d'entrer une valeur incorrecte, on doit voir le message "Votre candidat est trop vieux ou trop jeune" Vous y créerez également un champ NombreEnfant avec le bon type de données. Il ne sera pas possible d'indiquer plus de 6 enfants. Dans le cas ou on écrit une valeur incorrecte, le message "Le nombre d'enfants est incorrect" doit apparaître. Entrez-y les données suivantes :  |
0 commentaires:
Enregistrer un commentaire