Problème requêtes

Résolu/Fermé
domi6226 Messages postés 79 Date d'inscription jeudi 12 juillet 2012 Statut Membre Dernière intervention 5 juin 2018 - 5 juil. 2013 à 00:05
castours Messages postés 2955 Date d'inscription lundi 18 septembre 2006 Statut Membre Dernière intervention 31 août 2019 - 8 juil. 2013 à 15:58
Bonsoir à tous,

j'ai un petit souci sous ACCESS.

Je vais essayé d'être clair.

Je suis en train de créer une base de données avec différentes tables.

table 1 : joueur

table 2 : adhérents qui reprends certains éléments de la table 1 (avec une relation) et des informations complémentaires (comme adresse...) ; car les joueurs ne sont pas forcément des clients.

table 3 : produits sacs

table 4 : produits boule

+ 5 autres tables d'autres produits ou évènements (tel que tournoi, repas...).

J'essaye de créer une requête pour faire un suivi qui reprends ces éléments par adhérents.

Mon souci est que tous les adhérents ne participent pas à tout.

J'ai créé une table de base que j'ai appelé "Suivi" avec :

Ref adhérents en relation avec ref joueur de la table 1
réf produit sac en relation avec ref produit sac ; etc...

afin de rapatrier les éléments des tables correspondants à cette référence.

Mais ACCESS me dit qu'il ne trouve pas de correspondance dans le cas ou un des produits n'a pas de référence connue dans la table correspondante puisque je ne saisie aucune des références de la dite table.

je pourrai créer une table générale de produits ou évènements mais il me semble mieux de les séparer et elle serait trop importante et plus compliqué à gérer ; c'est pour cela que j'ai créé une table par produit.

J'espère avoir été assez limpide dans cette explication.

Si vous avez une astuce ou une solution, je suis preneur mais je ne suis pas un as du VBA.

Merci à vous.

4 réponses

castours Messages postés 2955 Date d'inscription lundi 18 septembre 2006 Statut Membre Dernière intervention 31 août 2019 217
5 juil. 2013 à 23:43
Bonjour
Pour eviter des doublons d'adresses dans cette table , je te suggere de mettre 2 case a cocher oui/nom.
Lors du remplissage du formulaire tu coches si il est joeur ou client ou les deux.
0
domi6226 Messages postés 79 Date d'inscription jeudi 12 juillet 2012 Statut Membre Dernière intervention 5 juin 2018
Modifié par domi6226 le 7/07/2013 à 07:43
J'ai changé d'option, j'ai modifié ma table adhérent en regroupant les tables joueurs et adhérents.

Le premier souci est donc est résolu, mais mon souci est ailleurs maintenant.

Dans ma table suivi, j'ai un numéro de demande en Numauto.

J'ai créé un formulaire en partant de ma table suivi et des sous-formulaire en partant des ref des autres tables (sac, boule, cours, repas, tournoi...)

Quand je saisi, ce numéro s'incrémente pour chaque sais dans les sous-formulaire.

Du coup, si un adhérent a dans la même demande un cours un repas et un tournoi j'ai 3 numéros de demande au lieu d'un.

Comment puis je faire pour que ce numéro ne change pas à chaque saisie dans les sous-formulaires.

Merci de votre aide car je galère sur ce truc, en plus ce problème résolu, j'aurai fini ma base et fini le suivi manuel.
0
heliconius Messages postés 539 Date d'inscription mardi 1 juillet 2008 Statut Membre Dernière intervention 23 juin 2023 139
8 juil. 2013 à 00:10
Bonsoir,

J'ai arrêté la lecture à la définition de la table 2. Celle dit précise que : "les joueurs ne sont pas forcément des clients". Ceci revient à dire que des joueurs peuvent aussi être adhérents. Dans ce cas là, on pourrait trouver un MARTIN Jean (joueur-adhérent) dans la table joueur d'une part et dans la table adhérents d'autre part.

Erreur. Il y aurait redondance d'information. Qu'il s'agisse d'adhérent, de joueur, d'organisateur, d'entraîneur ou qu'il remplisse un autre rôle une personne est une personne et elle va dans la table personnes et ce serait bien si l'ADN pouvait servir d'identifiant. C'est la relation qui sera établie avec un autre objet de gestion qui définira le rôle de la personne.

[PERSONNES]-0,n-----(Jouer)-----1,n-[MATCH]
[PERSONNES]-0,n-----(Payer)-----1,n-[COTISATION]

et rien n'empêche le même MARTIN Jean de participer aux deux relations. Ce serait dans ce cas, un joueur adhérent. Si le MARTIN Jean ne participe jamais à la relation Payer, ce serait un joueur non adhérent et s'il ne participe jamais à la relation Jouer, ce serait un adhérent non joueur.

Ceci, que je considère comme une erreur, est à mon humble avis la conséquence d'une absence d'analyse de la gestion à informatiser ou d'une analyse insuffisante.

Imaginons -pourquoi pas- qu'il faille gérer les cotisations (puisqu'on parle d'adhérents) et que le prix des cotisations puisse varier en fonction des situations (genre tarif couple). Il y aurait une table des maris et une table des femmes ??? Non ! Relation reflexive. Une seule et même table :
[PERSONNES]-0,1-----(Marié à)-----0,1-[PERSONNES]

[PERSONNES]       [PERSONNES]
IDpers: 12        IDpers: 47
nom: MARTIN       nom: DURAND
Prenom: Jean      prenom: Isabelle
champs...         champs...
marié à: 47       marié a: 12

On crée rarement des tables pour faciliter la création de requêtes. La base de données avec ses tables doit refléter la réalité du fonctionnement. Si c'est bien conçu, les requêtes viennent facilement sans bidouillages.

Pour la suite, "produits sacs" et "produits boule" : ça correspond à quoi ?
0
domi6226 Messages postés 79 Date d'inscription jeudi 12 juillet 2012 Statut Membre Dernière intervention 5 juin 2018
8 juil. 2013 à 06:18
Merci pour la réponse "philosophique", je me suis rendu compte de l'erreur et j'ai donc changé ma base de fonctionnement et ouvert un nouveau sujet car tout fonctionne sauf sur le champs Numauto.
0
castours Messages postés 2955 Date d'inscription lundi 18 septembre 2006 Statut Membre Dernière intervention 31 août 2019 217
8 juil. 2013 à 15:58
Bonjour
Pour une aide plud facile, je tsuggere de mettre ta base sur ce site avec C_joint.com
0