![]() |
![]() |
Leçon 5 |
![]() |
Effacement /déplacement de champs, types numériques, validations, champs vides
|
Dans cette leçon, nous allons apprendre à déplacer et effacer des champs, puis à utiliser les nombres dans nos champs. Nouverrons également comment restreindre les données possibles, nous gérerons également les champs vides et personnaliserons les messages d'erreurs de saisie. |
Sommaire
|
Nous allons ajouter la taille de nos clients. Ce ne serait une donnée utile que dans le cas où notre entreprise propose des vêtements sur-mesure.
Dans notre cas, la taille va simplement nous permettre d'étudier le type de données numérique.
Ouvrez votre base de données Formagiciel, comme d'habitude, et ouvrez la table T_Client en mode création.
Ajoutez un champ Taille :
Placez ce nouveau champ entre Prenom et VilleHabitation. Pour ce faire
Lancez la table en mode saisie de données :
Vous pouvez également changer la place des colonnes en mode saisie de données. Le principe est exactement le même : vous cliquez sur le champ Taille, et vous le faites glisser à gauche ou à droite.
Déplacez-le entre NomClient et Prenom :
Mon conseil : évitez donc de déplacer les champs en mode saisie de données.
Pour effacer un champ, par contre, vous pouvez le sélectionner en mode création, ou en mode saisie de données, et appuyer sur . Le résultat sera le même : une boîte de dialogue vous prévient que le champ va être supprimé, ainsi que toutes ses données.
C'est à dire que si vous effacez le champ Prenom, hop, tous les prénoms sont effacés, sans aucune possibilité d'annuler.
Bien. Si vous avez effacé le champ Taille, recréez-le, et replacez-le entre Prenom et VilleHabitation.
Remplissez les tailles des différents clients avec ces données (Quelque peu fantaisistes, je vous l'accorde) :
Ensuite, triez par cette colonne Taille.
Comme vous le constatez, le tri ne sert à rien : les données sont trop désordonnées : Dans un tri, les vides arrivent toujours en premier (Patrick Bruel : Taille inconnue). Ensuite, nous avons :
L'ordinateur doit transformer toutes les lettres en chiffres (et ensuite en code binaire) pour pouvoir trier. En bref, quand on a du texte à trier, le PC regarde combien "vaut" telle ou telle lettre, selon un tableau de correspondance, dont voici un extrait (L'original se trouve ici).
par exemple, "A" vaut 65... le signe "%" vaut 37. "a" (minuscule, donc) vaut 97, etc.
Les chiffres sont aussi codés ! "6" vaut 54, par exemple.
Ainsi, la chaîne de caractère Poire vaut : 80 - 111 - 105 - 114 - 101
Le chiffre 1.79 vaut, selon le même principe : 49 - 46 - 55 - 57.
Maintenant, vous devriez comprendre comment Access a effectué son tri, et pourquoi il a mis 1M69 après 174, et pourquoi il a mis Deux Mètres en dernier.
Ainsi, tant qu'il s'agit de texte, cette manière de trier est excellente, mais quand il s'agit de chiffres, c'est complètement nul.
Transformez ce champ texte en champ Numérique, comme ceci :
Lancez ensuite la table en mode saisie de données.
![]() |
Un message d'erreur vous informe qu'il est possible que certaines données soient perdues. Mais peut-être que non... En fait il affiche systématiquement ce message quand on change de type de champ vers un autre type de champ plus restrictif. |
D'ailleurs, le 2ème message d'erreur est carrément plus clair :
Vous avez deviné desquels il s'agit ?
Il arrive a Access de trier parfois par une colonne, parfois par une autre, selon son humeur (ou des paramètres que je ne connais pas). Ce qui explique pourquoi les gens ne sont pas forcément dans le même ordre avant et après le changement de type de données.
Dans l'usage quotidien d'Access, cet état de fait n'est pas du tout gênant, car on peut re-trier à tout moment depuis n'importe quel champ (sauf les mémos, rappelez-vous).
Si on comprend pourquoi les données textuelles sont perdues, en revanche, on peut se demander pourquoi il a arrondi 1.79 à 2 et 1.48 à 1.
Cet état de fait est inhérent à la structure interne des données, et c'est une notion ennuyeuse, donc je vais faire bref !
Les textes sont limités en nombre de caractères, tandis que les nombres sont limités en grandeur et en décimales. Par exemple, vous comprenez bien que le nombre 12 a besoin de moins de place mémoire que le nombre 5'992'438'998.34928701.
Octet, Entier, Entier Long, etc. sont des sous-types numériques. par exemple, Octet permet des chiffres entre 0 et 255, sans possibilité de décimales (Par exemple, pour un champ NombreEnfant, ça irait très bien)
Réel double, à l'inverse, lui, permet des chiffres énormes ou très précis, qui peuvent aller jusqu'à 15 chiffres. Par exemple, 992876735431542, ou 2323454327654.23, ou même 0.00000000023402.
Ce type de nombres pourraient être utiles si vous êtes astrophysicien, par exemple.
Vous pourriez vous dire que pour être sûr, vous allez mettre tous vos numériques en Réel Double... Oui mais sachez qu'Octet nécessite la place d'un seul caractère, tandis que Réel Double en a besoin de ... 8 ! (Même si vous y stockez de petits nombres)
Les autres sous-types de numériques ont des tailles intermédiaires, vous pouvez voir le détail ici.
C'est dans cette liste que ça se passe :
D'une manière générale, retenez deux choses :
Comme le sous-type par défaut, lorsque vous choisissez du numérique est Entier Long, il refuse donc les décimales.
Lorsque nous avons converti notre champ de texte à Numérique (Entier Long, donc), Access à arrondi les nombres au nombre entier le plus proche. 1.79 devient 2 et 1.48 devient donc... 1 !
Et ce n'est pas la peine d'essayer de récupérer les décimales, ou d'annuler : elles ont réellement disparu. D'ailleurs, si vous essayez de réécrire 1.48 à la place de 1 dans la date d'Edith Piaf, il va remettre 1, point-barre !
Du coup, si on veut pouvoir mettre des décimales, vous devez choisir Réel simple dans la liste :
Maintenant, vous pouvez rétablir les tailles d'origine :
Si vous essayez à nouveau d'entrer du texte dans un champ numérique , dès que vous allez cliquer dans un autre champ, ou que vous appuyez sur ENTER, un message vous rappelle à l'ordre.
Vous avez la possibilité de cliquer sur "Aide avec les types et les formats de données", mais vous allez simplement arriver sur une page très complète qui va vous "expliquer" en long, en large et en travers, les spécificités des types de données comme si vous étiez un grand spécialiste. Pas la peine de cliquer, donc.
Disons que Chaplin mesure en réalité 1.79, mais trompez-vous exprès, et écrivez 11.79 (11 au lieu de 1).
Il nous reste donc à régler quelques erreurs de taille :
Pour gérer ces types d'erreurs, nous allons réfléchir "informatiquement"... En fait, ce qui serait bien, ce serait d'interdire toute valeur supérieure a 2.5 (en supposant que personne ne mesure plus de 2M50).
En mode création, allez dans le champ Taille, et modifiez la propriété Valide Si, comme ceci : écrivez-y <2.5.
Lancez la table en mode saisie de données. Un message apparaît :
Il vous informe qu'il va peut être y avoir un problème, puisque tout-à-coups, vous refusez tous les nombres supérieurs à 2.5, c'est normal ! Mais il n'a pas vérifié... Il demande s'il doit vérifier. Dites Oui.
Parmi les boîtes de dialogue les plus difficiles à comprendre, je crois bien que celle-ci a la palme !
On ne va même pas essayer : dites oui, faites-moi confiance.
Comme vous le constatez, nous avons un peu les mêmes problèmes que tout à l'heure, quand nous avons changé un type de données Texte en Numérique, mais il y a une différence notable : Access n'a pas effacé les tailles incriminées !
Corrigeons les erreurs : modifiez 174 en 1.74, et enregistrez (Je pense que vous savez faire ça, maintenant ).
Et maintenant, faisons un truc de dingue : re-changez à nouveau 1.74 en 174, comme avant, et enregistrez à nouveau :
Eh oui : ce n'est plus possible.
Par contre, le message d'erreur "Une ou plusieurs valeurs sont interdites gna gna gna..." n'est pas facilement compréhensible ! Enfin, pour vous, oui, parce que nous venons de bidouiller dans la propriété Valide Si, mais imaginez une personne qui entre les données, sans connaître Access, et qui se retrouve devant ce message... Ca ne va pas être facile. Heureusement qu'on peut cliquer sur Aide !
Eh bien voilà ! Maintenant on comprend tout de suite ce qui se passe !!!
Non, je plaisante, on n'y comprend rien.
Avec le premier message, on ne comprenait pas grand chose, mais en regardant le message d'aide qui nous informe d'une Erreur 3317, on se tape carrément la tête contre les murs !
Tout ça parce qu'on s'est trompé, et qu'on ne peut pas entrer une valeur supérieure à 2.5 !
Si vous ne comprenez pas l'aide intégrée de Microsoft, ne vous inquiétez pas : moi non plus !
De version en version, quel que soit le programme, Microsoft a toujours rédigé l'aide intégrée comme s'ils s'adressaient à des programmeurs qui ont 20 ans de carrière derrière eux. Ah, elle est complète, c'est vrai ! Mais quand on a besoin d'aide, ça veut bien dire qu'on ne comprend pas... Du coup, en ce qui me concerne, lorsque j'ai un souci avec Access, je vais directement chercher la solution en allant sur Google, sans même essayer d'ouvrir l'aide Access !
Tiens : n'est-ce pas ainsi que vous avez justement trouvé mon cours ?
Terminons de corriger nos erreurs :
Afn de minimiser les risques d'erreurs, on pourrait aussi interdire les valeurs inférieures à 1, en admettant qu'aucun client ne mesure moins d'un mètre...
C'est facile, il suffit d'écrire Entre 1 et 2.5, dans les propriétés de Taille : .
Mais par contre, si l'on voulait pouvoir écrire 0 dans le cas ou une personne refuse d'indiquer sa taille, ce ne serait plus possible, puisque 0 n'est pas un nombre inclus entre 1 et 2.5. Nous allons affiner la formule pour qu'elle accepte aussi le 0 : 0 Ou Entre 1 et 2.5.
Par exemple, si nous ignorons la taille de Patrick Bruel, nous laissons le champ vide, et si Edith Piaf refuse de voir sa petite taille affichée, nous pourrions indiquer 0 (pour faire la distinction, et surtout pour vous montrer que rien et 0, ce n'est pas pareil)
Si vous vouliez que les valeurs vides soient interdites, la manoeuvre est différente. Pour ce faire, nous allons utiliser la colonne des prénoms. Faut-il accepter qu'un client n'ait pas de prénom ? A priori, non ! ... Et pourtant ... Entrez Coluche comme nouveau client (il mesure 1.71M et habite Lausanne)
Il n'a donc pas de prénom (En fait, si, c'est Michel Colucci, mais, on va dire qu'il n'avait pas de prénom, d'accord ? ).Revenez en mode création, et définissez la propriété de Prénom Null Interdit : Oui.
Lancez ensuite la table en mode saisie de données (on se doute qu'il va y avoir un souci, puisque, justement, on avait entré un client sans prénom juste avant :
Et on a un message qu'on commence à connaître :
Il nous a laissé le prénom de Coluche tout vide, pas de souci !
Mais à partir de maintenant, plus question d'entrer un nouveau client sans prénom ! Essayez d'entrer Disney, et de sauvegarder :
Comme nous ne voulons pas ajouter ce client, cliquez sur OK, et appuyez sur pour l'annuler.
Par contre, et attention, parce que c'est très finaud, il est possible de supprimer un prénom existant !
Essayez de supprimer Charlie (Sélectionnez-le en noir, et effacez le)
Enregistrez le changement, et O surprise ! Pas de message d'erreur de la part d'Access !
C'est comme si vous possédiez un appartement : vous avez le droit de ne rien mettre dedans (c'est à dire "pas de locataire"), mais, s'il y a un locataire, vous n'avez pas le droit de le virer pour le remplacer par "rien"... Il y a une difflérence entre "ne rien mettre" et "mettre rien".
dans notre cas, c'est tout le contraire : on a le droit de "mettre rien", mais pas "de ne rien mettre".
Si vous désirez donc interdire de mettre "rien" dans un prénom existant, alors, c'est la propriété Chaîne vide autorisée qu'il faut mettre à Non. Essayez !
Lancez ensuite votre table en mode saisie de données et essayez de supprimer Max, et enregistrez :
Afin d'éviter de vous embrouiller, lorsque vous désirez exiger le remplissage d'un champ, mettez à la fois Null Interdit à Oui, et Chaîne Vide Autorisée à Non.
Pour le prénom, laissez Null Interdit à Non, et Chaîne vide autorisée à Oui. Ainsi, nous pourrons ajouter de nouveaux clients tels que Coluche, mais si un prénom existe à un moment donné, il n'est pas logique de pouvoir le supprimer (mais vous pouvez avoir un autre avis).
Revenons à notre histoire de Taille : nous en étions au fait que les tailles permises s'échelonnent entre la valeur 0 ou entre 1 et 2.5. Si on entre une valeur non-permise, on obtient ce message d'erreur indigeste :
Nous avons la possibilité de remplacer ce message par un message de notre cru !
En cas de valeur invalide, nous dirons à l'utilisateur :
"Attention : la taille du client s'exprime en mètres : vous pouvez entrer une valeur entre 1 et 2.50. Entrez 0 si le client ne désire pas indiquer sa taille.".
Pour ce faire, allez dans la propriété Message si erreur du champ Taille :
Lancez la table en mode création, et essayez de préciser que Steven Spielberg mesure 3.57. Changez de champ ou d'enregistrement.
la réaction est immédiate :
Vous constatez que mon message d'erreur est affiché sur 3 lignes, alors que chez vous, il est peut-être plus long, un peu comme ceci :
C'est votre affichage qui est juste : lorsque j'ai pondu ce cours, j'ai parfois bidouillé les copies d'écran pour que ce soit plus esthétique, agréable à lire. Ne vous inquiétez donc pas si vous avez quelques différences de mises en forme telles que celles-ci.
Pensez à appuyer sur la touche pour revenir à l'ancienne valeur 1.79, sinon il va vous réafficher ce message sans arrêt.
Mauvaise nouvelle : si vous écrivez du texte à la place de chiffre, comme on a vu plus haut dans cette leçon, vous devez vous taper un message d'erreur bien indigeste.
Oui, je sais, c'est complètement ballot, mais c'est ainsi !
Il faudra attendre de faire de la programmation dans les formulaires pour se permettre le luxe de la création d'un message d'erreur personnalisé dans tous ces cas particuliers, mais nous n'en sommes pas là !
Bref... Revenez en mode création. Prenons la peine de documenter notre champ : précisez qu'on le laisse vide si on ne connait pas la taille, et qu'on met 0 si le client refuse de la préciser, comme ceci :
Cette zone de description sert donc à décrire les champs en détails.
On pourrait indiquer toutes les descriptions, comme ceci :
Mais concernant le prenom, la ville ou la remarque, ça n'a pas d'intérêt.
Lancez la table en mode saisie de données, et cliquez dans une taille : vous apercevez la description de votre champ dans la barre d'état, tout en bas de votre écran, sur la gauche :
C'est vraiment très (trop ?) discret, c'est vrai !
Ce qui serait bien, ce serait que dans le titre de la colonne, ce soit écrit non pas simplement
Taille
mais plutôt :
Taille (En mètres)
On pourrait bien entendu modifier le nom du champ, mais je ne veux pas utiliser des caractères tels que des espaces, des parenthèses ou des accents, comme je vous l'ai déjà dit.
Alors, nous allons utiliser la propriété Légende, essayez !
Lancez ensuite la table en mode saisie de données : Le titre de la colonne Taille prend la légende, tandis que les autres champs gardent leur désignation d'origine.
On a ainsi le beurre et l'argent du beurre , sympa, non ?
Si vous travaillez avec Access 2007, vous aurez un message d'erreur lors de l'ouverture de la table T_Client, de la base de données telle qu'elle est à la fin de cette leçon. Ca semble être dû à l'utilisation de fonctionnalités uniquement présentes dans la version 2010, mais, après relecture de cette leçon, je ne vois pas ce qui peut être à l'origine de cette erreur... Du coup, je ne peux vous proposer qu'une seule solution : aquérir Access 2010
Dans cette leçon, nous avons donc vu comment déplacer un champ en mode saisie de données et en mode création. Nous avons vu également comment supprimer un champ entier (avec toutes les données qu'il contenait).
Nous avons vu que lorsqu'on a besoin de nombres dans un champ, il ne faut pas le laisser en type texte, mais le transformer en Numérique (avec ou sans décimales selon les usages).
Nous avons enfin regardé comment ajouter une contrainte numérique pour ne pas que l'utilisateur entre n'importe quelle valeur, nous avons personnalisé le message d'erreur en cas d'infraction, nous avons vu comment gérer les champs vides, nous avons vu comment ajouter une description aux champs, ainsi que la possibilité de changer visuellement le nom d'une colonne sans toucher à la dénomination du champ.
Vous êtes un médecin, et vous désirez créer une base de données de gestion de vos patients.
L'exercice consiste à créer une base de données ExerciceLecon005.accdb.
Vous y créerez une table appelée T_DossierMedical.
Vous y créerez 4 champs :
Les colonnes devront apparaître visuellement comme ceci :
Les noms doivent être obligatoirement remplis (Les prénoms peuvent rester vides)
L'age est une valeur entière autorisée entre 18 et 120 (Valeur restant vide si on ne la connaît pas). En cas de saisie erronnée, le message "Les mineurs ne sont pas autorisés dans ce cabinet médical". Il faut ajouter la description suivante au champ : "Si l'age n'est pas connu, estimer l'àge à 10 ans près"
Le poids est indiqué à 0.5 KG près (Mais on ne vérifiera pas si un poids est "trop précis" : on acceptera 58.2 par exemple), et ne peut excéder 200 (on ne doit pas pouvoir entrer un poids en dessous de zéro, logique !).
Voici un exemple de la table un peu remplie:
Constatez que le message d'erreur concernant les mineurs s'affiche aussi lorsque l'age est supérieur à 120. Ce n'est pas réellement un bug, mais une limitation : on n'a droit qu'à un seul message d'erreur par champ.