Salut,
Tu dois te relire *avant* d'envoyer, cela évite de polluer
avec 3 messages pour la même question !
En ce qui concerne ta question :
Un groupe d'option est un élément graphique qui ne permet de
choissir une seul élément parmis ceux proposés et en retourne
la valeur numérique.
Point barre !
Si tu souhaite que la valeur retournée représente un certain
enregistrement dans une table, c'est à toi d'aller le chercher
et/ou te t'adresser à celui qui va bien...
En tout cas, un item d'un groupe d'options ne peut pas être
directement et automatiquement lié à un enregistrement.
*** Il suffirait d'ailleurs d'ajouter un deul enregistrement à la dite
table pour que ton groupe d'option soit caduque !!!
--
A+
Pierre (3stone) Access MVP
"Jac"
| j'aimerais créer un groupe d'option qui s'appuierait sur une
| requête contenant uniquement 1 enregistrement et 5 champs.
| Chaque bouton du groupe d'options doit afficher une des
| valeurs de ces cinq champs.
|
| Mais quand je me lance dans la création d'un groupe d'option,
| Access ne me propose pas autre chose que de remplir à la main
| les valeurs à afficher. Et comme ces données sont susceptibles
| de changer, j'aimerais ne pas avoir à expliquer aux utilisateurs
| comment en faire la mise à jour.
| Y a-t-il une façon d'arriver expliquer à Access qu'il doit se servir
| des variables contenues dans la requête cible ?
Salut,
Tu dois te relire *avant* d'envoyer, cela évite de polluer
avec 3 messages pour la même question !
En ce qui concerne ta question :
Un groupe d'option est un élément graphique qui ne permet de
choissir une seul élément parmis ceux proposés et en retourne
la valeur numérique.
Point barre !
Si tu souhaite que la valeur retournée représente un certain
enregistrement dans une table, c'est à toi d'aller le chercher
et/ou te t'adresser à celui qui va bien...
En tout cas, un item d'un groupe d'options ne peut pas être
directement et automatiquement lié à un enregistrement.
*** Il suffirait d'ailleurs d'ajouter un deul enregistrement à la dite
table pour que ton groupe d'option soit caduque !!!
--
A+
Pierre (3stone) Access MVP
"Jac"
| j'aimerais créer un groupe d'option qui s'appuierait sur une
| requête contenant uniquement 1 enregistrement et 5 champs.
| Chaque bouton du groupe d'options doit afficher une des
| valeurs de ces cinq champs.
|
| Mais quand je me lance dans la création d'un groupe d'option,
| Access ne me propose pas autre chose que de remplir à la main
| les valeurs à afficher. Et comme ces données sont susceptibles
| de changer, j'aimerais ne pas avoir à expliquer aux utilisateurs
| comment en faire la mise à jour.
| Y a-t-il une façon d'arriver expliquer à Access qu'il doit se servir
| des variables contenues dans la requête cible ?
Salut,
Tu dois te relire *avant* d'envoyer, cela évite de polluer
avec 3 messages pour la même question !
En ce qui concerne ta question :
Un groupe d'option est un élément graphique qui ne permet de
choissir une seul élément parmis ceux proposés et en retourne
la valeur numérique.
Point barre !
Si tu souhaite que la valeur retournée représente un certain
enregistrement dans une table, c'est à toi d'aller le chercher
et/ou te t'adresser à celui qui va bien...
En tout cas, un item d'un groupe d'options ne peut pas être
directement et automatiquement lié à un enregistrement.
*** Il suffirait d'ailleurs d'ajouter un deul enregistrement à la dite
table pour que ton groupe d'option soit caduque !!!
--
A+
Pierre (3stone) Access MVP
"Jac"
| j'aimerais créer un groupe d'option qui s'appuierait sur une
| requête contenant uniquement 1 enregistrement et 5 champs.
| Chaque bouton du groupe d'options doit afficher une des
| valeurs de ces cinq champs.
|
| Mais quand je me lance dans la création d'un groupe d'option,
| Access ne me propose pas autre chose que de remplir à la main
| les valeurs à afficher. Et comme ces données sont susceptibles
| de changer, j'aimerais ne pas avoir à expliquer aux utilisateurs
| comment en faire la mise à jour.
| Y a-t-il une façon d'arriver expliquer à Access qu'il doit se servir
| des variables contenues dans la requête cible ?
Salut,
"Jac"
| Mea culpa... c'était ma première pollution. Je ferai mon possible pour
que
| cela ne se reproduise plus...
Il suffit de comprendre que ce sont des "conversations" qui ont lieu ici,
aussi appelé des "fils de discussions". On reste donc dans la conversation
tant que celle-ci n'est pas close ou aboutie.
| Mais j'ai rappelé les messages, donc ceux qui
| n'ont pas regardé le groupe entre 17h et 18h30 ne devraient pas être
| importunés.
On relance une question le lendemain (au plus tôt) et sûrement pas dans
l'heure
qui suit !!! Les personnes présentes n'ont peut être pas comprise ta
question
ou ne possède pas la réponse. Et...personne n'est payé pour te répondre!
Si tu pense que ta question n'était pas claire ou précise, ajoute les
précisions
tout en restant dans le fil que tu à engendré.
| Je reviens à ma question :
oui ;-)
|ma requête n'affichera jamais plus qu'une seule
| ligne. Cinq champs ont pour valeurs actuellement Pierre, Paul, Jacques,
| Marcel et Jean. Ce que je cherche, c'est afficher ces prénoms face aux
| boutons de mes groupes d'option et faire en sorte que quand Pierre sera
| remplacé par Robert, dans la table correspondante, face à mon premier
| bouton, ce soit Robert qui s'affiche.
Il faudra(it) assigner à l'étiquette qui va bien, le contenu de ton champ.
Passer pour cela par la propriété "Caption" (Me!Etiquette0.Caption = ...)
Ce qui ne corrige pas le fait que tu as un gros problème de normalisation
de ta base de données.
Pierre, Paul et Jacques ne peuvent PAS se trouver dans des champs
différents,
mais bien dans le MÊME champ, mais d'enregistrements différents.
Comme quoi, les souhaits particuliers trouvent souvent leurs origines dans
une mauvaise conception de la base.
--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
Conseils MPFA: http://www.mpfa.info/
Salut,
"Jac"
| Mea culpa... c'était ma première pollution. Je ferai mon possible pour
que
| cela ne se reproduise plus...
Il suffit de comprendre que ce sont des "conversations" qui ont lieu ici,
aussi appelé des "fils de discussions". On reste donc dans la conversation
tant que celle-ci n'est pas close ou aboutie.
| Mais j'ai rappelé les messages, donc ceux qui
| n'ont pas regardé le groupe entre 17h et 18h30 ne devraient pas être
| importunés.
On relance une question le lendemain (au plus tôt) et sûrement pas dans
l'heure
qui suit !!! Les personnes présentes n'ont peut être pas comprise ta
question
ou ne possède pas la réponse. Et...personne n'est payé pour te répondre!
Si tu pense que ta question n'était pas claire ou précise, ajoute les
précisions
tout en restant dans le fil que tu à engendré.
| Je reviens à ma question :
oui ;-)
|ma requête n'affichera jamais plus qu'une seule
| ligne. Cinq champs ont pour valeurs actuellement Pierre, Paul, Jacques,
| Marcel et Jean. Ce que je cherche, c'est afficher ces prénoms face aux
| boutons de mes groupes d'option et faire en sorte que quand Pierre sera
| remplacé par Robert, dans la table correspondante, face à mon premier
| bouton, ce soit Robert qui s'affiche.
Il faudra(it) assigner à l'étiquette qui va bien, le contenu de ton champ.
Passer pour cela par la propriété "Caption" (Me!Etiquette0.Caption = ...)
Ce qui ne corrige pas le fait que tu as un gros problème de normalisation
de ta base de données.
Pierre, Paul et Jacques ne peuvent PAS se trouver dans des champs
différents,
mais bien dans le MÊME champ, mais d'enregistrements différents.
Comme quoi, les souhaits particuliers trouvent souvent leurs origines dans
une mauvaise conception de la base.
--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
Conseils MPFA: http://www.mpfa.info/
Salut,
"Jac"
| Mea culpa... c'était ma première pollution. Je ferai mon possible pour
que
| cela ne se reproduise plus...
Il suffit de comprendre que ce sont des "conversations" qui ont lieu ici,
aussi appelé des "fils de discussions". On reste donc dans la conversation
tant que celle-ci n'est pas close ou aboutie.
| Mais j'ai rappelé les messages, donc ceux qui
| n'ont pas regardé le groupe entre 17h et 18h30 ne devraient pas être
| importunés.
On relance une question le lendemain (au plus tôt) et sûrement pas dans
l'heure
qui suit !!! Les personnes présentes n'ont peut être pas comprise ta
question
ou ne possède pas la réponse. Et...personne n'est payé pour te répondre!
Si tu pense que ta question n'était pas claire ou précise, ajoute les
précisions
tout en restant dans le fil que tu à engendré.
| Je reviens à ma question :
oui ;-)
|ma requête n'affichera jamais plus qu'une seule
| ligne. Cinq champs ont pour valeurs actuellement Pierre, Paul, Jacques,
| Marcel et Jean. Ce que je cherche, c'est afficher ces prénoms face aux
| boutons de mes groupes d'option et faire en sorte que quand Pierre sera
| remplacé par Robert, dans la table correspondante, face à mon premier
| bouton, ce soit Robert qui s'affiche.
Il faudra(it) assigner à l'étiquette qui va bien, le contenu de ton champ.
Passer pour cela par la propriété "Caption" (Me!Etiquette0.Caption = ...)
Ce qui ne corrige pas le fait que tu as un gros problème de normalisation
de ta base de données.
Pierre, Paul et Jacques ne peuvent PAS se trouver dans des champs
différents,
mais bien dans le MÊME champ, mais d'enregistrements différents.
Comme quoi, les souhaits particuliers trouvent souvent leurs origines dans
une mauvaise conception de la base.
--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
Conseils MPFA: http://www.mpfa.info/
Salut,
"Jac"
[...]
| Je ne suis pas sûr qu'il s'agisse ici de mauvaise conception de la base.
| Pierre, Paul et Jacques se trouvent être des titres de champs car ils
| s'occupent de secteurs géographique différents et comme il s'agit de
leur
| planing, les enregistrements correspondent à des dates et l'intersection
| date avec un des cinq intervenants me permet de mettre en place leurs
| rendez-vous. Voilà pourquoi c'est dans ce sens là.
La raison n'est pas plus suffisante/meilleure qu'avant...
- Qu'arrive t-il si tu embauches/ajoutes un secteur géographique ?
- Comment feras tu une recherche "en horizontal" ?
Les données doivent *toujours* se retrouver rangées "en vertical"
dans les tables, quelque soit la "présentation" souhaitée par la suite.
Et question fun, une liste, déroulante ou non, apporte la même facilité
de saisie tout en s'adaptant à une quantité variable d'items, mais avec
l'avantage que les données seront basées sur une table bien conçue !
Salut,
"Jac"
[...]
| Je ne suis pas sûr qu'il s'agisse ici de mauvaise conception de la base.
| Pierre, Paul et Jacques se trouvent être des titres de champs car ils
| s'occupent de secteurs géographique différents et comme il s'agit de
leur
| planing, les enregistrements correspondent à des dates et l'intersection
| date avec un des cinq intervenants me permet de mettre en place leurs
| rendez-vous. Voilà pourquoi c'est dans ce sens là.
La raison n'est pas plus suffisante/meilleure qu'avant...
- Qu'arrive t-il si tu embauches/ajoutes un secteur géographique ?
- Comment feras tu une recherche "en horizontal" ?
Les données doivent *toujours* se retrouver rangées "en vertical"
dans les tables, quelque soit la "présentation" souhaitée par la suite.
Et question fun, une liste, déroulante ou non, apporte la même facilité
de saisie tout en s'adaptant à une quantité variable d'items, mais avec
l'avantage que les données seront basées sur une table bien conçue !
Salut,
"Jac"
[...]
| Je ne suis pas sûr qu'il s'agisse ici de mauvaise conception de la base.
| Pierre, Paul et Jacques se trouvent être des titres de champs car ils
| s'occupent de secteurs géographique différents et comme il s'agit de
leur
| planing, les enregistrements correspondent à des dates et l'intersection
| date avec un des cinq intervenants me permet de mettre en place leurs
| rendez-vous. Voilà pourquoi c'est dans ce sens là.
La raison n'est pas plus suffisante/meilleure qu'avant...
- Qu'arrive t-il si tu embauches/ajoutes un secteur géographique ?
- Comment feras tu une recherche "en horizontal" ?
Les données doivent *toujours* se retrouver rangées "en vertical"
dans les tables, quelque soit la "présentation" souhaitée par la suite.
Et question fun, une liste, déroulante ou non, apporte la même facilité
de saisie tout en s'adaptant à une quantité variable d'items, mais avec
l'avantage que les données seront basées sur une table bien conçue !