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
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
A voir également:
- Problème requêtes
- Nos systèmes ont détecté un trafic exceptionnel sur votre réseau informatique. cette page permet de vérifier que c'est bien vous qui envoyez des requêtes, et non un robot. que s'est-il passé ? - Forum MacOS
- Expliquez les différences entre les différentes requêtes ✓ - Forum Réseaux sociaux
- N26 votre appareil a envoyé trop de requêtes sur une courte période de temps. veuillez patienter. - Forum Consommation & Internet
- Différence entre une requête et une transaction - Forum Bases de données
- Adn trop de requêtes. veuillez réessayer plus tard ✓ - Forum Facebook
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
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.
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.
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
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.
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.
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
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.
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 :
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 ?
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 ?
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
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.
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
8 juil. 2013 à 15:58
Bonjour
Pour une aide plud facile, je tsuggere de mettre ta base sur ce site avec C_joint.com
Pour une aide plud facile, je tsuggere de mettre ta base sur ce site avec C_joint.com