Discussion :

[Pierre Fauconnier]

Salut.

Perso, j'ai des difficultés à concevoir que la partie gauche d'une égalité dans une clause WHERE pointe vers autre chose qu'un champ de la source de données (et donc vers un contrôle de formulaire, dans ce cas-ci). Pour moi, ça sent le défaut de conception.

Il serait intéressant d'expliquer ce que tu souhaites obtenir, et de quoi tu pars

[tee_grandbois]

bonjour Pierre,
en fait, la mauvaise conception vient du fait que les activités sont en colonne et qui plus est, le libellé de l'activité EST le nom du champ. Il aurait été préférable d'avoir une table des activités et une autre table contenant la relation clé client/ Clé activité, mais passons ....
Cela demande juste une petite instruction SQL qui prendrait le nom du champ obtenu à partir de la liste déroulante en VBA. Exemple dans le cas où on utilise un sous-formulaire où Modifiable0 contient le nom du champ:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
Private Sub Modifiable0_AfterUpdate()
Dim strSQL As String
 
strSQL = "SELECT [NOM-PRENOM], TELEPHONE, EMAIL, '" & Me.Modifiable0.Value & "' as Activité" _
& " from ADHERENTS where [" & Modifiable0 & "] = True;"
Me.SF1.Form.RecordSource = strSQL
 
End Sub

cela prend moins de 2 minutes, mais pas avec une requête enregistrée et une Macro Access

[Pierre Fauconnier]

On peut me raconter ce qu'on veut, je pense que c'est un ineptie d'avoir une valeur liée à un formulaire dans la "partie gauche" d'une clause WHERE...

[tee_grandbois]

la liste déroulante est basée sur une liste de champs ...

[Pierre Fauconnier]

Et?

Qu'est-ce que ça change? Si on analyse la requête sql, ça donne quoi? Ca donne que la clause WHERE renvoie True ou False pour toutes les lignes, non? Autrement dit, la sélection ne se fait pas "ligne par ligne" ce qui est le fondement même de la clause WHERE, mais pour l'ensemble des lignes, puisque la condition ne change pas "ligne par ligne"...

[tee_grandbois]

oui, si tu te bases sur l'existant:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
SELECT ADHERENTS.[NOM-PRENOM], ADHERENTS.TELEPHONE, ADHERENTS.EMAIL, [Formulaires]![ADHERENTS]![liste-activites] AS Activité
FROM ADHERENTS
WHERE [Formulaires]![ADHERENTS]![liste-activites]![Texte]=True;

mais ceci donne quelque chose de complètement différent exécuté sous VBA:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
Private Sub Modifiable0_AfterUpdate()
Dim strSQL As String
 
strSQL = "SELECT [NOM-PRENOM], TELEPHONE, EMAIL, '" & Me.Modifiable0.Value & "' as Activité" _
& " from ADHERENTS where [" & Modifiable0 & "] = True;"
Me.SF1.Form.RecordSource = strSQL
 
End Sub

car Modifiable0 renvoie le nom d'un champ et du coup, la requête est reconstruite

[pilule007]

la liste déroulante est basée sur une liste de champs ...

Bonjour,
merci pour ton aide,
mais je n'arrive pas à n'obtenir que les membres qui sont inscrit à telle ou telle activité,
je vais changer et créer une table avec les activités, avec les champs IDactivite et nom_activite , et créer une autre table activites_adherents reprenant IDadherent , IDactivite , (comme tu le préconises)
mon problème sera de pouvoir inscrire le membres à plusieurs activités et les enregistrer en 1 seule fois (il y 22 activités différentes) avec chaque fois 1 ligne dans la table activites_adherents

Autre petite question,
as tu un livre à me conseiller pour apprendre access

merci beaucoup
pilule007

[tee_grandbois]

je vais changer et créer une table avec les activités, avec les champs IDactivite et nom_activite , et créer une autre table activites_adherents reprenant IDadherent , IDactivite , (comme tu le préconises)

ah dommage, je viens juste de modifier ta base, je m'apprêtait à la livrer ...

[pilule007]

ah dommage, je viens juste de modifier ta base, je m'apprêtait à la livrer ...

ah, si cela fonctionne, je veux bien essayer, je n'ai encore rien fait, je réflechissais à la manière de programmer de nouveau

[Pierre Fauconnier]

Donc si je comprends bien, on va construire du brol ma torché sur du brol mal torché. Ca va être rigolo quand on va changer les valeurs dans la table en basant des noms de champs sur des valeurs métier...

Règle de base: Les noms de champs ne doivent JAMAIS être des données "métier"...On a encore essayé de faire passer des inepties dans cette discussion à propos des codes Insee comme clés primaires, mais je maintiens que c'est un ineptie et que toute construction non basée sur ce concept de base est vouée à devenir une usine à gaz qui pètera un jour ou l'autre. Plus on persistera, plus ça coûtera cher le jour où ça pètera.


Mais bon, apparemment, il est préférable de s'enferrer dans l'erreur plutôt que de reconstruire proprement. Triste monde. On atteint des sommets sur nos forums.

[pilule007]

Donc si je comprends bien, on va construire du brol ma torché sur du brol mal torché. Ca va être rigolo quand on va changer les valeurs dans la table en basant des noms de champs sur des valeurs métier...

Règle de base: Les noms de champs ne doivent JAMAIS être des données "métier"...On a encore essayé de faire passer des inepties dans cette discussion à propos des codes Insee comme clés primaires.

Mais bon, apparemment, il est préférable de s'enferrer dans l'erreur plutôt que de reconstruire proprement. Triste monde. On atteint des sommets sur nos forums.

Bonjour,
désolé mais je découvre un peu access, j'ai déjà programmé par le passé en visual basic, mais manifestement, ce n'est pas la meme chose,
aurais tu un bon livre à me conseiller pour que je puisse apprendre correctement access

merci beaucoup
pilule007

[tee_grandbois]

@ Pierre Fauconnier: OK, j'ai bien compris les principes, dont acte.

du brol ma torché sur du brol mal torché

le brol, par contre, je ne connais pas.

@ pilule007:
voici la nouvelle base modifiée :ADHERENTS-VIDE_retour.zip
elle a 3 nouveaux objets, 2 formulaires:
- ACTIVITEJOURNALIERE sous-formulaire
- F_ACTIVITEJOURNALIERE
1 module:
- mFonctionsCommunes
la fonction ListeChamps() permet de sélectionner uniquement les champs correspondant à une activité dans la table ADHERENTS (code fournit par EricDgn dans cette discussion) et adapté à ton besoin.
1 formulaire a été modifié:
ADHERENTS
j'ai remplacé la macro par du code VBA pour charger F_ACTIVITEJOURNALIERE (à la place de la requête ACTIVITEJOURNALIERE)
pour tester coche "ANGLAIS DEBUTANT", "ANGLAIS NIVEAU 2" et "BELOTE".
libre à toi de remplacer (ou pas) les objets créés et modifiés.
Tu auras ensuite tout loisir à monter ta base de données de manière plus relationnelle ...

[Pierre Fauconnier]

[...]le brol, par contre, je ne connais pas.[...]

Brol = Truc mal torché. Brol mal torché = truc mal torché mal torché = truc (mal torché)² = usine à gaz = boum à +/- brève échéance.

Je sais que ça fait ch*** quand je dis qu'il faut respecter les bonnes pratiques, mais je m'en fous un peu. Ce truc, mal torché sur base de trucs mal nommés, pètera un jour ou l'autre à la gu figure de l'utilisateur.

Ca plait ou pas, mais c'est comme ça!

[...]
Tu auras ensuite tout loisir à monter ta base de données de manière plus relationnelle ...

Le problème, c'est que les conseilleurs ne sont pas les payeurs, et que comme une "solution" existe, elle va être appliquée sur le truc mal torché mal torché, ce qui amènera à déployer d'autres astuces pour faire tenir le truc mal torché qu'on a mis sur le truc mal torché... Parce qu'avant que l'utilisateur "ait le loisir de monter sa base de données... blablabla", il coulera de l'eau sous les ponts et lorsque sa base pètera dans tous les sens, les "conseilleurs" ne seront pas là pour éponger...


Mais j'dis ça, j'dis rien... Continuez comme ça. Après tout, ce n'est pas ma base de données...

[pilule007]

...

super
cela fonctionne très bien
merci beaucoup pour ton aide
pilule007

[Pierre Fauconnier]

[...]
aurais tu un bon livre à me conseiller pour que je puisse apprendre correctement access[...]

Oui et non: Il y a dans notre section Livres quelques critiques de livres et tu peux t'en inspirer pour faire ton choix. Tu as également notre section "tutoriels" dans laquelle tu devrais trouver ton bonheur.

Au départ, c'est une question de bonne conception, car sans elle, tu seras très vite dans l'impasse:

• Pas de clé primaire avec une signification métier;
• Pas de noms de champs avec une signification métier;
• Pas de noms de champs avec des espaces, des accents, ...;
• ...

On peut te laisser croire que tu es dans le bon et te pondre du code vba pour coller stricto sensu à ta demande, mais je pense que c'est te rendre un très mauvais service.

[...]
Tu auras ensuite tout loisir à monter ta base de données de manière plus relationnelle ...

Au risque d'en indisposer quelques-uns, je ne peux que contester cette position. On ne construit pas une maison sur des fondations en carton-pâte en se disant "Bah, on rectifiera plus tard". Quand les données auront été saisies "en vrai", on ne reviendra pas sur la conception car on n'aura pas le temps, et l'on s'apercevra que la démarche consistera alors à tout détruire et tout recommencer. Perso, je pense que c'est dès maintenant qu'il faut revoir la conception, sinon, quand s'y mettre? Quand l'usine à gaz pètera à la figure de l'utilisateur?

La structure actuelle de la base mène à l'impasse, c'est une vérité incontestable sur le plan technique, et il est primordial de réfléchir à son modèle de données et de respecter les règles AVANT de se lancer dans la conception des tables, formulaires, etc. Avec une bonne conception, on n'a pas besoin du développement en VBA qui t'est proposé et qui n'est là que parce que le truc est mal torché au départ, et que ce truc va nécessiter demain un nouveau bricolage en VBA pour pallier la prochaine lacune de conception.

Le besoin d'avoir les noms des champs dans une liste déroulante devrait nous alerter sur le problème éventuel d'organisation des tables, car ce besoin est suffisamment rare que pour nous interpeller et nous obliger à mettre le doigt là où ça fait mal.


Dans une base Access, au risque de me répéter, on ne met pas des données comme noms de champs. Or les activités proposées sont des données et doivent donc se trouver dans les tables au lieu d'en constituer la structure. Ici:

• la structure reprend les 24 activités comme champs OUI/NON de la table des adhérents;
• il manque la table des activités quotidiennes (le programme, en quelque sorte);
• il manque la table qui lie les adhérents aux activités quotidiennes;
• le type d'activité, tel que repris dans la table "Activités" devrait être déclaré pour l'activité "Belote", et pas pour la programmation d'une belote en septembre (sinon, on va devoir répéter l'info pour les prochains tournois de belote, au risque de se tromper, de mal orthographier, empêchant ainsi tout traitement ultérieur des données;
• ...
• ...

Ca veut dire que:

• l'évolution de ta base est compromise puisque ta conception est caduque;
• tu te prives des sous-formulaires qui te permettent une interface conviviale, pratique et pérenne sans VBA (tout du moins pou r95% de tes besoins);
• tes requêtes vont être inutilement compliquées, lentes à l'exécution, et certaines seront tout simplement impossibles à réaliser;
• lorsque tu ajouteras une activité (anglais 3, italien 1, ...), tu devras modifier la structure de ta base (ajout du champ dans la table, ajout du contrôle dans le formulaire, ajout de la table "nouvelle activité" à l'instar de la table "belote" que j'ai trouvée dans le fichier proposé sur le site;
• ...

Dans ton cas, nul besoin de VBA pour réaliser ta base de données. Sur ce que j'ai compris de ta base, tu gères les participations des membres d'une maison culturelle ou autre à des activités proposées par l'association. 6 tables bien conçues permettent de réaliser pas mal de choses (au moins 95% de tes besoins, je pense) sans VBA:



Avec cette conception, chaque info n'est inscrite qu'une seule fois dans la base, dans la table qui la gère. Tout le reste se déduit des liaisons entre les tables, et cette conception, qui a pris une quinzaine de minutes, permet de créer les formulaires présents dans le fichiers en deux clics de souris et d'attaquer les données par n'importe quel axe de saisie, de regard ou d'analyse.







Ce n'est bien entendu qu'une ébauche, mais qui illustre comment tu peux concevoir et organiser tes tables, requêtes, formulaires en respectant les règles de création d'une base de données relationnelle. Tu verras ici que tu peux ajouter des données dans les tables et les retrouver dans les listes déroulantes des autres tables qui sont liées. On pourra bien entendu ajouter des tables, des requêtes, des formulaires, et le VBA viendra en appui pour automatiser ou améliorer l'ergonomie, mais pas pour pallier les manques d'une conception bancale. Ici, on pourrait ajouter des légendes aux champs des tables pour avoir des étiquettes de contrôle plus conviviales que les noms de champs (possibilité de mettre des espaces, des accents, ...).

Si tu comprends bien le schéma des relations, que tu perçois la facilité avec laquelle les listes déroulantes sont créées et la simplicité de la construction de formulaires avec sous-formulaires comme illustré dans le fichier joint, tu as déjà compris beaucoup de choses d'Access et de la conception d'un système de gestion de données relationnelles.

Bon travail si tu décides de t'appuyer sur mon modèle.

[marot_r]

Bonjour.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

[Formulaires]![ADHERENTS]![liste-activites]![Texte]=True;

Ton champ [liste-activites], qu'est-ce ? Parce qu'une liste déroulante cela a peu de chances de contenir True.
Si par contre ta "liste déroulante" offre plusieurs choix cochables alors ce n'est pas une liste déroulante mais un champ multivalué (soit une table dans un champ) et c'est une toute autre bête :-).
Ici des articles sur les champs multi-valués :

https://access.developpez.com/faq/?page=MultiValue
https://warin.developpez.com/access/multivalue/

Et personnellement je ne m'en sert pas je préfère une vraie table d'association, une architecture du genre :

tblElement
ClefElement

tblDetail
ClefDetail

tblAssElementDetail
ClefAssElementDetail
ClefElement
ClefDetail

Qui s'intègre beaucoup mieux avec les autres outils de Access.

A+

[Pierre Fauconnier]

@René,

La conception de cette base est expliquée dans cette discussion. Reste à voir ce que Pilule va choisir parmi les solutions qui sont proposées (Quand on parlait de bonne et de mauvaise conception... )

[pilule007]

@René,

La conception de cette base est expliquée dans cette discussion. Reste à voir ce que Pilule va choisir parmi les solutions qui sont proposées (Quand on parlait de bonne et de mauvaise conception... )

Bonjour,
pour le moment, cela fonctionne très bien avec la solution proposée par un des membres de ce site, et je l'en remercie vivement.

Mais je vais évoluer vers une table 'activites_choix' qui reprendra les clés primaires des tables adherents et activites (je l'avais déjà fait pour les journées-activités culturelles, qui fonctionne très bien) , je le ferai aussi pour les voyages proposés par l'association,

Ce sera plus facile pour moi,

De plus je voudrais par après créer un formulaire qui reprendra la synthèse d'un adhérent : cotisation payée ou non, choix de ses activités, de ses journées-activités culturelles et de ses voyages, j'ai vu qu'il existait des formulaires et des sous formulaires, sait-on mettre 3-4 sous formulaires dans un formulaire, ou bien uniquement 1 ?

Merci
pilule007

[Pierre Fauconnier]

J'ai fusionné les deux discussions.

Il sera intéressant que tu publies les schémas de tes tables (PAS les fichiers Access) afin de savoir vers quoi tu te diriges.

[Pierre Fauconnier]

[...]j'ai vu qu'il existait des formulaires et des sous formulaires, sait-on mettre 3-4 sous formulaires dans un formulaire, ou bien uniquement 1 ?[...]

Tu peux en mettre plusieurs, tu peux même les mettre en cascade. Tout dépendra de la conception, bonne ou "moins bonne" ("On" m'a dit dans l'oreillette qu'il n'y a pas de mauvaise conception ), de ta base