Afficher des colonnes extraites d'une liste déroulante

J’ai mis en place une liste déroulante sur un formulaire, mais celle-ci ne m’affiche qu’une seule valeur. Comment faire apparaître dans le formulaire les autres colonnes de la liste ?

Dans l’exemple ci-dessous, une liste affiche différents clients. Après le choix d’un client, il faudrait afficher le code client (ce qui est automatiquement géré par la liste déroulante), mais également le nom et le prénom du client.

Mise en place

L’une des méthodes pour récupérer la valeur d’une colonne de liste déroulante consiste à créer un champ calculé.
On suppose que vous vous avez construit la liste déroulante. Pour afficher les 2 autres colonnes de cette liste, procédez comme suit :

  1. Ouvrez votre formulaire en mode Création.
  2. Cliquez sur votre liste déroulante.
  3. Cliquez sur l’icône Propriétés en haut de l’écran
  4. Dans la boîte de propriétés, cliquez sur l’onglet Autres.
  5. Cliquez dans la propriété « Nom », et donnez un nom à votre liste déroulante (par ex. : lstClients). 
  6. Si nécessaire, faites apparaître la boîte à outils, via le menu Affichage / Boîte à outils.
  7. Cliquez sur l’icône Zone de texte puis cliquez quelque part sur le formulaire (une zone de texte indépendante devrait apparaître).
  8. Cliquez dans cette zone, et tapez : =[lstClients].Column(1)
  9. Cliquez sur l’icône Zone de texte puis cliquez à nouveau sur le formulaire.
  10. Cliquez dans cette zone, et tapez : =[lstClients].Column(2)
  11. Vous pouvez également, via la boîte de propriétés, donner des noms plus clairs à vos 2 zones de texte (par ex. : txtNom et txtPrenom).

Notes
  • La fonction Column() sera peut-être retraduite en français par Access.
  • Les colonnes sont numérotées de 0 à n-1 (dans mon exemple, les numéros de clients représentent la colonne 0, les noms la colonne 1, et les prénoms la colonne 2).

Vous aimerez aussi...

50 réponses

  1. y dit :

    c’est une solution nikel
    solution approuvé!!!!!

  2. Hervé Inisan dit :

    Demarche Jean-Marc > La question est identique à celle de Pierre, précédemment. Et ma réponse aussi. 🙂 Il n’y a pas besoin de reproduire les infos Villes dans la table Contacts, dans la mesure où les 2 tables sont liées par une clef. Cette clef commune permet la liaison, et permet donc d’extraire le CP et la ville par une requête.

    Si on recopie le CP et la Ville dans la table Contacts…

    1. On se retrouve avec des doublons sur ces infos : tous les contacts de CP = 78800 et Ville = Houilles auront ces 2 infos dupliquées autant de fois. Or l’idée est d’éviter les doublons dans une base de données.
    2. Si la ville change de nom (rare, mais c’est d’actualité 😉 ), il faut penser à modifier tous les contacts de cette ville. Donc risque d’erreur, de données obsolètes, etc.

    Alors que sans duplication, pas de doublons sur la ville, et il suffit de renommer Houilles en Oville dans la table des villes (1 seule saisie), et le tour est joué.

    Quant au changement de nom de cette ville, ça reste à voir aux prochaines élections ! 🙂

  3. Demarche Jean-Marc dit :

    J’ai créé une base de donnée avec une table contact qui reprend tout les champs classiques, nom, prénom, adresse code postal, numéro de téléphone… J’ai téléchargé une table code postaux avec toutes les localités belge et leurs codes postaux. J’aimerai savoir comment dans mon formulaire contact je pourrais avoir une liste déroulante avec localité + code postal et que les données qui viennent de ma table code postaux soient injectées dans les champs localité et code postaux de ma table Contact? Je sais qu’il existe la Fonction Column. Cette fonction m’injecte localité dans localité mais le code postal dans ma table contact reste désespérément vide. Pourriez-vous m’apporter votre aide. Je vous en remercie d’avance.

  4. Hervé Inisan dit :

    pierre > Au contraire. Je pense que tu raisonnes « façon Excel », où toutes les données sont sur une même liste. Dans une base de données, les informations sont « dispatchées » sur plusieurs tables, justement pour améliorer la saisie et la cohérence des données.

    Est-ce que tu as des notions d’analyse ? En d’autres termes :

    • Savoir identifier les tables d’un projet
    • Connaître les notions de clef primaire et de clef étrangère

    Si ce n’est pas le cas, jette un œil sur cette série d’articles. Tu verras notamment pourquoi on a besoin d’une table Villes, et comment elle est construite.

    Et bien que les infos soient dans 2 tables (Clients + Villes), ça ne pose pas de problème d’exploitation : une requête Access te permettra ensuite de regrouper Clients et Villes, et d’afficher correctement les infos sur ta fiche Client.

  5. pierre dit :

    oui mais alors ca ne sert rien arien une liste deroulante moi le but c ‘est de simplifier la saisie pour eviter les erreurs de saisie c est pour cela que j ai une base de ville code postal departement qui quand je saisie la ville en la sélectionnant sur la fiche contact j affiche bien le code postal et la departement mais si ma table cotnact n’est pas mise a jour cela n ‘a aucun interet pour moi

  6. Hervé Inisan dit :

    pierre > C’est normal et correct. S’il y a 2 tables (par ex. : Clients et Villes), l’objectif de la base de données est de stocker chaque information 1 seule fois, au meilleur endroit possible. Le code postal n’est pas une information Client, c’est une information Ville. C’est pour ça :

    1. Qu’il figure dans la table Villes.
    2. Qu’il n’a pas besoin d’être stocké dans la table Clients.

    Comme les 2 tables sont liées, on peut n’importe quand extraire (par requête) les informations Clients + Villes, dont le code postal.

  7. pierre dit :

    re, bon c bon j’arrive a afficher mon code postal dans la zone code postal mais il ne mets pas a ma jour ma table contact si bien que le code postal n’est jamais saisie en realité

  8. jll dit :

    Herve je pense avoir compris ta question oui ma liste fonctionne bien quand je suis sur mon formulaire de saisie je vois bien la liste des villes si je sélectionne une ville cela marche bien et ma fiche contact se mets bien a jour sans pb mais le code postal ne se met pas a jour automatiquement comme je le souhaiterais

  9. jll dit :

    tu entent koi par la liste fonctionne
    je precise je debute en access je comprend pas tres vite ( et blond d orginie je plaisante )

  10. Hervé Inisan dit :

    jll > Est-ce que la liste fonctionne ? Est-ce qu’il peut y avoir une erreur de syntaxe dans la formule (notamment sur le nom de la liste) ?

  11. jll dit :

    dsl ca ne marche pas moi je ne comprend pas j ai une liste de ville et par rapport au choix de la ville je veux afficher le code postal et le departement

  12. Hervé Inisan dit :

    mimi > Et dans chaque zone de texte, est-que tu as bien une formule du type :

    Il faut aussi que la liste déroulante contienne un nombre suffisant de colonnes (puisque c’est elle qui fournit les informations).

  13. mimi dit :

    salut,
    J’ai le même problème que le celui qui a poster le commentaire n19
    Je dois afficher 5 autres colonnes et ça m’affiche que 2 colonnes…
    des suggestions,?? (j ai bien creer autant de zone de texte qu’il le faut
    merci

  14. Hervé Inisan dit :

    Zoe603 > Le plus simple est de continuer la conversation sur le forum Access, ce sera plus facile pour échanger. Tu peux par exemple poster ta base (compressée) sur un site comme cjoint.com, puis poster le lien dans ta question du forum. On se retrouve là-bas ! 🙂

  15. Zoe603 dit :

    Bonjour,
    Je dois faire une erreur quelque part que je ne vois pas. Si toutefois je n’arrive pas à m’en sortir peut être pourrais-je envoyer cette base quelque part où tu pourras la récupérer. J’aimerai bien y arriver car dans le commerce rien n’existe qui corresponde à mon besoin.
    Merci encore

  16. Hervé Inisan dit :

    Zoe603 > Donc on reprend 🙂

    1. La table contient les champs sans « T ».
    2. Tous les champs démarrant par « T » sont calculés dans la requête.
    3. Du coup, je ne vois pas pourquoi la table ne montre que les champs Aliments et Quantité. Idem pour la requête : elle contient les champs de la table + les champs calculés, si j’ai suivi ?
    4. Si le formulaire est lui-même basé sur cette requête (et non pas sur la table), il récupère les champs calculés de la requête comme des champs normaux. On doit pouvoir écrire en pied de formulaire un =Somme([TGlucides]) par exemple.

    Ou bien… ?

  17. Zoe603 dit :

    Pour Hervé Hinisan.
    Désolé de t’importuner mais mon explication n’a pas du être correcte.
    Ma table comprend:
    Date; Aliments; Glucides; Lipides; Protides; Calories;
    Tglucides;Tlipides;Tprotides;Tcalories.
    Ma requête comprend les mêmes champs avec les calculs suivants:
    Tglucides:[Glucides]*[Quantite] et idem pour les autres colonnes
    Pour le formulaire la seule façon que j’ai eu pour afficher les colonnes liées a été ton astuce =[Aliments].[Column](1)-(2) etc…
    Pour calculer ma ligne j’ai fait =[Aliments].[Column](1)*[Quantite]
    Si j’ai mangé 80gr de Pain complet à 0,49 glucides je totalise 39,2
    Comme il y a plusieurs aliments par jour il me faut additionner la colonne Tglucides et c’est là que cela coince.
    Pour info, seuls les champs (aliments) et (quantité) sont visibles dans ma table et ma requête

  18. Hervé Inisan dit :

    Zoe603 > Si j’ai suivi, les champs de la table sont présents dans le formulaire. Donc faire un calcul par rapport à la liste ne m’a pas l’air utile. Il suffirait de créer ce champ calculé :

    et le total pourrait se faire effectivement par =Somme([Champ calculé précédent])

  19. Zoe603 dit :

    Merci pour la réponse. Le formulaire et la liste sont basés sur une requête simple elle même issue d’une table.
    Ce calcul à pour but d’additionner chaque jour la quantité de glucides consommés (je suis diabétique)
    Donc grâce à l’astuce fournie j’ai pu afficher les informations de la liste (colonnes liées (4)). Puis sur la même ligne le calcul =[Aliments].[Column](1)*[Quantite] me donne le résultat consommé sur l’aliment. Me reste à trouver l’astuce pour additionner la colonne. D’habitude sur le pied de formulaire le champ commence par =Somme([…….?……])Impossible d trouver la bonne formule

  20. Hervé Inisan dit :

    Zoe603 > Est-ce que tu peux préciser sur quelle source sont basés le formulaire et la liste ? Et quel calcul tu souhaites faire précisément à partir de ça ?

  21. Zoe603 dit :

    Merci pour l’astuce. Mais le encontre un problème. Je n’arrive pas à additionner les colonnes. Je me retrouve avec la formule
    =[Aliments].[Column](1)*[Quantite]
    Mais dans le pied d formulaire je n’arrive pas à créer l’expression qui m’additionnera la colonne. Un conseil serai le bienvenu
    Merci d’avance

  22. Hervé Inisan dit :

    RV > Il vaut mieux passer par du VBA plutôt que par des macros (le code sera plus court et plus facile à faire évoluer). Surtout qu’ici il faut une boucle sur ItemSelected, ce qui est laborieux par macros. Cet autre article du Grenier montre comment faire en VBA.

  23. RV dit :

    Quelle est la syntaxe pour tester la Xème valeur d’une liste déroulante à sélection multiple, dans une expression de macro Access 2010 ?

  24. Hervé Inisan dit :

    jojo > C’est normal : il faut une boucle pour extraire toutes les valeurs d’une liste à sélection multiple (parce qu’il y a… sélection multiple ;-)). Voir cet article du Grenier. Du coup, on ne peut pas les extraire en une seule formule de champ calculé. Est-ce que ça ne serait pas plus lisible d’afficher un formulaire (ou un sous-formulaire) qui reprendrait les valeurs sélectionnées ?

  25. jojo dit :

    Merci pour la Réponse

    Cela fonctionne bien avec une liste déroulante Classique.
    Par-contre avec une liste déroulante à Multiple choix je n’ai rien dans ma zone texte.

    Pour un seul choix oui, mais pas pour plusieurs, dommage.

    Je souhaiterais afficher dans la zone texte les renseignements de plusieurs enregistrements sélectionnés grâce à la liste déroulante Multi choix, par exemple :

    Référence article A, Désignation article A ; Référence article B, Désignation article B ; Référence article F, Désignation article F ;

  26. Hervé Inisan dit :

    Jojo > Dans mon exemple, il y a 2 zones de texte : chacune affiche une info unique, venant d’une colonne de la liste déroulante.

    Si tu veux les 2 infos dans la même zone de texte, il faut concaténer les résultats. Du style :

  27. Jojo dit :

    Bonjour

    Avec une liste déroulante à choix multiples comment faire pour que la zone texte affiche plusieurs choix ?

    Cela fonctionne bien avec un choix, mais quand on sélectionne 2 ou plus la zone texte est vide.

    Merci

  28. Hervé Inisan dit :

    lotocariste > Dans ce cas, il ne faut pas utiliser Column(), parce qu’il s’agit plutôt d’une recherche d’enregistrement. La solution consiste donc à créer une liste déroulante (avec l’Assistant) pour effectuer cette recherche. La procédure est détaillée sur la page Ajouter une liste déroulante de self-access.com. Ouala !

  29. lotocariste dit :

    Bonjour, J’ai utiliser avec succès la fonction column mais j’aimerais pouvoir remplir automatiquement les champs mais plutôt que d’utiliser une liste déroulante, je préfèrerais utiliser la réponse d’un champs. Par exemple je rentre mon numéro de clients et en validant sur entré, je souhaiterais que les champs nom prénom et adresse se complète automatiquement. Merci de votre aide

  30. Hervé Inisan dit :

    fbi > Tu as bien créé autant de zones de texte que de colonnes à afficher, avec à chaque fois la formule qui va bien ?

  31. fbi dit :

    Bonjour. J’utilise ACCESS 2007
    Un grand merci pour ce blog. Trés utile.
    Par contre, dans mon cas, la fonction Column ne fonctionne pas bien.
    Je dois afficher 5 autres colonnes et ça m’affiche que 2 colonnes…
    Je ne comprends pas.

  32. Hervé Inisan dit :

    Fizoup > L’outil le plus complet pour voir toutes les méthodes d’objets est l’Explorateur d’objets dans VBE. Tu as aussi l’Assistant en mode Requête, mais il est moins pratique et peut laisser écrire des erreurs. D’une manière générale, la syntaxe anglaise marche partout dans Access, alors que la syntaxe française ne passe que dans l’interface graphique (tables, requêtes, formulaires, états, mais pas dans les modules).

  33. Fizoup dit :

    Oui en effet c’était bien des zones de liste.
    Ma syntaxe était la suivante :
    Formulaires![form_principal]![lst_cde].Column(1) ou .colonne(1), j’ai essayé les 2.

    En fait, cette fonction n’apparait pas dans l’interface « Créer », mais la fonction « nz » (un grand merci pour l’astuce des critères vides) non plus et pourtant je n’ai pas eu de problème avec celle-ci.
    Est-ce qu’il est possible de voir la liste des foncutions applicables à un type d’objet (comme en VBA) ailleurs que dans VBA ?

    Pour l’instant, j’ai modifié les zones de liste en sous-formulaires pour contourner le problème, et finalement, ça me permet d’avoir une interface plus facile à utiliser (tri et largeur de colonne), donc je pense que je vais les garder pour la suite.

    Merci !

  34. Hervé Inisan dit :

    micpid > Quelle est la syntaxe que tu utilises ?

    Sinon, j’imagine que la première zone est une liste, pas une zone de texte (sinon effectivement, la méthode Column n’existe pas sur une zone de texte).

  35. Fizoup dit :

    Bonjour,

    J’ai un petit problème avec la fonction colonne et je voulais savoir si vous pouviez avoir une petite idée du pourquoi…

    Je suis entrain de faire un formulaire dans le lequel j’ai 2 zones de textes. La première affiche les caractéristiques d’une commande avec toutes ses positions, et je voudrais afficher les caractéristiques de la position sélectionnée dans la deuxième.

    Je souhaite récupérer les 2 premières colonnes (numéro de commande et numéro de la position) de la première zone de texte par l’intermédiaire de la fonction colonne() afin de les mettre en critères de la requete associée à la dexième zone de texte.

    Le problème c’est que Access (2003) me dit que la fonction colonne n’est pas définie…
    Est-ce que j’oublie de faire quelque chose ?

    Merci

  36. elyssa dit :

    vous avez raison, j avoue j ai jamais penser a ca

  37. chrisu dit :

    On peut clore le sujet. Je n’ai pas trouvé la solution à ce problème précis mais après discussion les requêtes ont été modifiées. A plus!

  38. Chrisu dit :

    * Est-ce que le but est d’afficher 1 seul résultat (paramétré) ? Un seul chiffre sur l’état ? OUI
    * La table [tbl Activity Monitoring] ne fait pas partie de la source de l’état ?NON
    C’est bien ça: le rapport est basé sur une requête par Villages: différentes activités et pour chaque activité des « targets » puis la somme des targets. C’est OK
    Le responsable aimerait en plus en bas de page avoir la valeur total des « targets » pour toute la vallée (donc pour tous les villages de la vallée). Avec un sous rapport basé sur une requête « Vallée » ça fonctionne. J’ai amélioré le design pour que les colonnes correspondent, pour supprimer les ascenseurs etc… et c’est pas trop mal mais c’est vraiment compliqué et peu satisfaisant.
    Si avec un champ calculé ou arrive au même résultat ce serait super…

  39. Hervé Inisan dit :

    Chrisu > Selon l’objectif à atteindre, il y a peut-être d’autres méthodes plus appropriées. Quelques questions :

    • Est-ce que le but est d’afficher 1 seul résultat (paramétré) ? Un seul chiffre sur l’état ?
    • La table [tbl Activity Monitoring] ne fait pas partie de la source de l’état ?

    Si les réponses sont « oui » et « non », DSum() peut convenir et on peut creuser. Mais si ton but est d’obtenir des sous-totaux par Valley, sur l’état, il faut faire autrement…

  40. Chrisu dit :

    Les paramètres Village et Valley proviennent d’une table: Tbl Activity Monitoring.
    J’ai tordu l’expression dans tous les sens (!!) pour résultat nul.
    Quand je mets:
    =DSum(« [Target planned] »; »Tbl Activity Monitoring »; »[Valley]=’Shishi' ») dans le report footer ça fonctionne: j’affiche toutes les données du champ Target planned et ses totaux pour le village Charsadda ainsi que les totaux du champ Target planned pour la vallée du village: Shishi.
    Le rapport est basé sur une requête [frm Parameters]![txtVillages].

  41. Hervé Inisan dit :

    Chrisu > Tout dépend d’où provient le paramètre. S’il vient d’un formulaire, par exemple, ça donnerait :

    =DSum("[Target planned]";"Tbl Activity Monitoring";"[Valley]='" & Forms![Nom du formulaire]![Nom d'un champ du formulaire] & "'")

  42. Chrisu dit :

    Dans l’expression:
    =DSum(« [Target planned] »; »Tbl Activity Monitoring »; »[Valley]=’Shishi' »)
    par quoi remplacer le nom de la vallée pour que je puisse changer le nom de la vallée à la demande avant d’ouvrir mon rapport? Je travaille sur un rapport d’activité par Village mais il faudrait ajouter la valeur au niveau vallée. J’arrive à avoir l’info en utilisant un sous rapport basé sur une requête « vallée » mais ce n’est pas beau côté design!
    Merci.

  43. chrisu dit :

    J’ai organisé la requête à partir des tables liées et c’est OK. En plus c’est simple et ce sera facile à expliquer à celui qui gérera la database.
    Merci.

  44. Hervé Inisan dit :

    chrisu > A priori, oui. On peut aussi le faire pour un formulaire (voir ici). Mais si c’est pour imprimer un document, c’est bien un état qu’il faut utiliser.

  45. chrisu dit :

    Pour pouvoir imprimer les données du champ dans un rapport je fais donc une query en utilisant la « table de la liste » et la table principale?
    Ou bien on peut faire une query à partir d’un formulaire?

  46. Hervé Inisan dit :

    chrisu > Quand tu dis « ne s’affichent pas », c’est « ne se stockent pas » je pense ? C’est normal, et c’est même mieux : sauf cas particulier (rare), il n’y a pas d’intérêt à stocker ces données dans la table, parce que :

    1. Elles existent déjà dans une autre table (la table qui alimente la liste).
    2. Le fait de les stocker encore créerait des doublons.
    3. On peut consulter les informations sur le formulaire.
    4. Si tu veux afficher les données de la table principale + celles de la liste, tu peux faire une requête qui assemble les 2 tables. Il y a probablement une relation 1:n entre la table principale et celle de la liste.

    Parmi les cas rares qui justifieraient un stockage : la liste déroulante affiche des informations Produits (dont le prix de base), et on souhaite dupliquer ce prix dans une table de facturation. Là en fait, il n’y a pas de doublon réel, parce que le prix de facturation peut être différent du prix de base. Dans ce cas, on procéderait comme indiqué sur cet article.

  47. chrisu dit :

    C’est OK dans les formulaires mais les données des colonnes liées ne s’affichent pas dans la table!

  48. Hervé Inisan dit :

    micpid > Oui, tout pareil.

  49. micpid dit :

    Bonjour
    Peut-on faire la même chose dans un état
    Cordialement

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *