Dans un formulaire, j'ai deux champs très classiques : CodePostal et Ville
Je souhaite pouvoir choisir la valeur pour chacun des champs, dans une
liste basée sur une table (qui contient quelques couples CP/Ville).
Pour code postal : pas de problème : la liste de choix présente bien mes
deux colonnes, et lorsque je clique sur l'une ou l'autre, c'est bien le
code postal qui est saisi.
Pour la ville : PROBLEME ! La liste de choix présente aussi les deux
colonnes, mais je n'arrive pas à définir la deuxième colonne (la ville)
comme valeur de saisie... il me met toujours le code postal !
... je précise que j'ai bien indiqué la colonne liée = 2 pour sélectionner
la ville.
Comme je suis curieux de nature, j'ai essayé d'intervertir l'ordre des
colonnes (Ville/CP au lieu de CP/Ville) ... et du coup, la colonne liée
devenant = 1 ... cela fonctionne !!!
Quel détail m'a echappé et m'empùeche d'utiliser une autre colonne que la 1
en tant que colonne liée ??
PS : soyez indulgent, je débute ! Il s'agit de ma première base ACCESS, et
je ne savais pas ce que c'était qu'une table il y a 5 jours !
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Pascal BENOIT
Dans ta table des "Localité", ce n'est pas le code postal et la ville qu'il faut sauver, mais y ajouter un champ IdLocalité.
Ce champ peut être un numéro auto.
Dans ta table des clients, membres ou personnes, c'est le champ IdLocalité que tu sauve.
Merci de ta réponse, mais je dois avouer que je n'ai pas vraiment compris la nécessité du champ IdLocalité dont tu me parles.
J'ai tout de même essayé, me retrouvant alors avec une table à 3 colonnes pour ma liste de choix ... et le problème reste le même pour la ville : c'est toujours le Code Postal qui y apparaît !
J'ai lu quelquepart dans un didacticiel que Access pouvait se planter quand on utilise autre chose que la colonne 1 d'une liste de choix multicolonnes, voilà ce qu'en disait l'auteur du lien ci-dessous : http://www.info-3000.com/access/supportdecours/lecon14/lecon14.htm
***************** début de citation
C'est ici que vous allez choisir la colonne qui va être mémorisée. En effet, quand vous allez choisir par exemple Jaune pour un client... C'est Jaune ou c'est Yellow que vous choisissez ? C'est Jaune, même si vous cliquez sur Yellow (Vois allez pouvoir tester ça dès que la liste sera terminée). C'est jaune... Pour autant que vois choisissiez Col1 ici même. Si vous choisissez Col2, ce seront les couleurs anglaises qui seront gardées en mémoire. Par expérience, je peux vous dire que vous avez intérêt de toujours sélectionner Col1 lorsque vous avez ces listes à plusieurs colonnes, sinon j'ai constaté qu'Access "pète un peu les plombs". Ce n'est pas vraiment un problème, car c'est sans doute toujours la première colonne la plus importante.
***************** fin de citation
Serait-ce donc un bug d'Access 2000 qui m'empêche de choisir la colonne 2 ?
Cordialement, Pascal.
Dans ta table des "Localité", ce n'est pas le code postal et la ville
qu'il faut sauver, mais y ajouter un champ IdLocalité.
Ce champ peut être un numéro auto.
Dans ta table des clients, membres ou personnes, c'est le champ
IdLocalité que tu sauve.
Merci de ta réponse, mais je dois avouer que je n'ai pas vraiment compris
la nécessité du champ IdLocalité dont tu me parles.
J'ai tout de même essayé, me retrouvant alors avec une table à 3 colonnes
pour ma liste de choix ... et le problème reste le même pour la ville :
c'est toujours le Code Postal qui y apparaît !
J'ai lu quelquepart dans un didacticiel que Access pouvait se planter quand
on utilise autre chose que la colonne 1 d'une liste de choix multicolonnes,
voilà ce qu'en disait l'auteur du lien ci-dessous :
http://www.info-3000.com/access/supportdecours/lecon14/lecon14.htm
***************** début de citation
C'est ici que vous allez choisir la colonne qui va être mémorisée. En
effet, quand vous allez choisir par exemple Jaune pour un client... C'est
Jaune ou c'est Yellow que vous choisissez ? C'est Jaune, même si vous
cliquez sur Yellow (Vois allez pouvoir tester ça dès que la liste sera
terminée). C'est jaune... Pour autant que vois choisissiez Col1 ici même.
Si vous choisissez Col2, ce seront les couleurs anglaises qui seront
gardées en mémoire. Par expérience, je peux vous dire que vous avez intérêt
de toujours sélectionner Col1 lorsque vous avez ces listes à plusieurs
colonnes, sinon j'ai constaté qu'Access "pète un peu les plombs". Ce n'est
pas vraiment un problème, car c'est sans doute toujours la première colonne
la plus importante.
***************** fin de citation
Serait-ce donc un bug d'Access 2000 qui m'empêche de choisir la colonne 2 ?
Dans ta table des "Localité", ce n'est pas le code postal et la ville qu'il faut sauver, mais y ajouter un champ IdLocalité.
Ce champ peut être un numéro auto.
Dans ta table des clients, membres ou personnes, c'est le champ IdLocalité que tu sauve.
Merci de ta réponse, mais je dois avouer que je n'ai pas vraiment compris la nécessité du champ IdLocalité dont tu me parles.
J'ai tout de même essayé, me retrouvant alors avec une table à 3 colonnes pour ma liste de choix ... et le problème reste le même pour la ville : c'est toujours le Code Postal qui y apparaît !
J'ai lu quelquepart dans un didacticiel que Access pouvait se planter quand on utilise autre chose que la colonne 1 d'une liste de choix multicolonnes, voilà ce qu'en disait l'auteur du lien ci-dessous : http://www.info-3000.com/access/supportdecours/lecon14/lecon14.htm
***************** début de citation
C'est ici que vous allez choisir la colonne qui va être mémorisée. En effet, quand vous allez choisir par exemple Jaune pour un client... C'est Jaune ou c'est Yellow que vous choisissez ? C'est Jaune, même si vous cliquez sur Yellow (Vois allez pouvoir tester ça dès que la liste sera terminée). C'est jaune... Pour autant que vois choisissiez Col1 ici même. Si vous choisissez Col2, ce seront les couleurs anglaises qui seront gardées en mémoire. Par expérience, je peux vous dire que vous avez intérêt de toujours sélectionner Col1 lorsque vous avez ces listes à plusieurs colonnes, sinon j'ai constaté qu'Access "pète un peu les plombs". Ce n'est pas vraiment un problème, car c'est sans doute toujours la première colonne la plus importante.
***************** fin de citation
Serait-ce donc un bug d'Access 2000 qui m'empêche de choisir la colonne 2 ?
Cordialement, Pascal.
3stone
Salut,
Pascal BENOIT
Dans ta table des "Localité", ce n'est pas le code postal et la ville qu'il faut sauver, mais y ajouter un champ IdLocalité.
Ce champ peut être un numéro auto.
Dans ta table des clients, membres ou personnes, c'est le champ IdLocalité que tu sauve.
[...] mais je dois avouer que je n'ai pas vraiment compris la nécessité du champ IdLocalité dont tu me parles.
J'ai tout de même essayé, me retrouvant alors avec une table à 3 colonnes pour ma liste de choix ... et le problème reste le même pour la ville : c'est toujours le Code Postal qui y apparaît !
Si tu crée un table des "Localités", ce n'est pas pour coller la localité de chacun dans la table des "Personnes"...
Imagine, 100 personnes qui habitent Paris, tu aurais 100 fois la ville "Paris" dans la table des "Personnes".
Ta liste à trois colonnes (dont les "Largeur" sont 0cm;2cm;5cm par exemple) La colonne liée est la première... (et cachée... on ne voit que le CP et Localité) Tu sauve donc dans la Table des "Personnes"... l'IdLocalité
De cette facon, tu n'as pas de doublons dans la table "T_Localités"
T_Personnes IdPersonne (clé primaire) NomPerso PrenomPerso AdressePerso IdLocalité (clé externe en relation avec IdLocalité de T_Localités) ...
-- A+ Pierre (3stone) Access MVP -------------------------------------- Une pour tous, tous pour une ;-) http://users.skynet.be/mpfa/ --------------------------------------
Salut,
Pascal BENOIT <pbenoit@teaser.fr>
Dans ta table des "Localité", ce n'est pas le code postal et la ville
qu'il faut sauver, mais y ajouter un champ IdLocalité.
Ce champ peut être un numéro auto.
Dans ta table des clients, membres ou personnes, c'est le champ
IdLocalité que tu sauve.
[...]
mais je dois avouer que je n'ai pas vraiment compris
la nécessité du champ IdLocalité dont tu me parles.
J'ai tout de même essayé, me retrouvant alors avec une table à 3 colonnes
pour ma liste de choix ... et le problème reste le même pour la ville :
c'est toujours le Code Postal qui y apparaît !
Si tu crée un table des "Localités", ce n'est pas pour coller la localité
de chacun dans la table des "Personnes"...
Imagine, 100 personnes qui habitent Paris, tu aurais 100 fois
la ville "Paris" dans la table des "Personnes".
Ta liste à trois colonnes (dont les "Largeur" sont 0cm;2cm;5cm par exemple)
La colonne liée est la première... (et cachée... on ne voit que le CP et Localité)
Tu sauve donc dans la Table des "Personnes"... l'IdLocalité
De cette facon, tu n'as pas de doublons dans la table "T_Localités"
T_Personnes
IdPersonne (clé primaire)
NomPerso
PrenomPerso
AdressePerso
IdLocalité (clé externe en relation avec IdLocalité de T_Localités)
...
--
A+
Pierre (3stone) Access MVP
--------------------------------------
Une pour tous, tous pour une ;-)
http://users.skynet.be/mpfa/
--------------------------------------
Dans ta table des "Localité", ce n'est pas le code postal et la ville qu'il faut sauver, mais y ajouter un champ IdLocalité.
Ce champ peut être un numéro auto.
Dans ta table des clients, membres ou personnes, c'est le champ IdLocalité que tu sauve.
[...] mais je dois avouer que je n'ai pas vraiment compris la nécessité du champ IdLocalité dont tu me parles.
J'ai tout de même essayé, me retrouvant alors avec une table à 3 colonnes pour ma liste de choix ... et le problème reste le même pour la ville : c'est toujours le Code Postal qui y apparaît !
Si tu crée un table des "Localités", ce n'est pas pour coller la localité de chacun dans la table des "Personnes"...
Imagine, 100 personnes qui habitent Paris, tu aurais 100 fois la ville "Paris" dans la table des "Personnes".
Ta liste à trois colonnes (dont les "Largeur" sont 0cm;2cm;5cm par exemple) La colonne liée est la première... (et cachée... on ne voit que le CP et Localité) Tu sauve donc dans la Table des "Personnes"... l'IdLocalité
De cette facon, tu n'as pas de doublons dans la table "T_Localités"
T_Personnes IdPersonne (clé primaire) NomPerso PrenomPerso AdressePerso IdLocalité (clé externe en relation avec IdLocalité de T_Localités) ...
-- A+ Pierre (3stone) Access MVP -------------------------------------- Une pour tous, tous pour une ;-) http://users.skynet.be/mpfa/ --------------------------------------
Anor
Bonjour,
3stone a élucidé : .../... | Imagine, 100 personnes qui habitent Paris, tu aurais 100 fois | la ville "Paris" dans la table des "Personnes".
et pour compléter ce que dit 3stone, l'intérêt d'avoir un IdLocalité est que si un jour, la ville de Paris décidait de s'appeler "Paris Beach", alors il suffirait de modifier 1 seule fois le nom de la localité dans la table "tblLocalites" plutôt que d'avoir à modifier cette occurence 100 fois dans la table "Personnes".
C'est ce qu'on appelle le principe de précaution ...euh d'intégrité référentielle.
Cela dit, par rapport à la colonne 1, personnellement, je préfère la colonne 0, puisque c'est celle là qui est ramenée comme valeur de liste par défaut lorsqu'on ne précise pas son numéro, mais je suppose que c'est ce qui était sous-entendu.
3stone <3stone@skynet.be> a élucidé :
.../...
| Imagine, 100 personnes qui habitent Paris, tu aurais 100 fois
| la ville "Paris" dans la table des "Personnes".
et pour compléter ce que dit 3stone, l'intérêt d'avoir un IdLocalité
est que si un jour, la ville de Paris décidait de s'appeler "Paris Beach",
alors il suffirait de modifier 1 seule fois le nom de la localité dans la table
"tblLocalites" plutôt que d'avoir à modifier cette occurence 100 fois dans la table
"Personnes".
C'est ce qu'on appelle le principe de précaution ...euh d'intégrité référentielle.
Cela dit, par rapport à la colonne 1, personnellement, je préfère la colonne 0,
puisque c'est celle là qui est ramenée comme valeur de liste par défaut
lorsqu'on ne précise pas son numéro, mais je suppose que c'est ce qui était sous-entendu.
3stone a élucidé : .../... | Imagine, 100 personnes qui habitent Paris, tu aurais 100 fois | la ville "Paris" dans la table des "Personnes".
et pour compléter ce que dit 3stone, l'intérêt d'avoir un IdLocalité est que si un jour, la ville de Paris décidait de s'appeler "Paris Beach", alors il suffirait de modifier 1 seule fois le nom de la localité dans la table "tblLocalites" plutôt que d'avoir à modifier cette occurence 100 fois dans la table "Personnes".
C'est ce qu'on appelle le principe de précaution ...euh d'intégrité référentielle.
Cela dit, par rapport à la colonne 1, personnellement, je préfère la colonne 0, puisque c'est celle là qui est ramenée comme valeur de liste par défaut lorsqu'on ne précise pas son numéro, mais je suppose que c'est ce qui était sous-entendu.
