Bonjour,
Comment éviter les doublons dans une requête ?
........................................................................
Je souhaite convoquer des adhérents ayant été membres ces trois
dernières années:
- une table adhérents
Avec un Champ : Nom
- une table adhésion
Avec un Champ années
Dans les champs -Nom certains ont été membres tous les ans et d'autres non.
.............................................................................
Dans ma requête j'ai demandé regroupement, mais j'ai du oublié autre chose
car ça ne fonctionne pas.
D'avance merci !
J'ai essayé les deux, mais elles me donnent un message d'erreur. L'important c'est que la première fonctionne avec la condition MAX. Merci à tout les deux.
Effectivement, il y avait une parenthèse en trop dans chacune des requêtes. Mille excuses.
db
SELECT DISTINCT T1.Titre, T1.[Prénom], T1.Nom, T1.Adresse1, T1.Adresse2, T1.[Code Postal], T1.Ville, T1.[retraité] FROM [adhérents] AS T1 INNER JOIN [adhésion] AS T2 ON T1.refadherent = T2.refadherent WHERE T1.[retraité]=True AND T2.[année]> 09 AND T2.[année]< 11 ORDER BY T1.Nom;
SELECT T1.Titre, T1.[Prénom], T1.Nom, T1.Adresse1, T1.Adresse2, T1.[Code Postal], T1.Ville, T1.[retraité], Max(T2.[année]) AS MaxDeannée FROM [adhérents] AS T1 INNER JOIN [adhésion] AS T2 ON T1.refadherent = T2.refadherent GROUP BY T1.Titre, T1.[Prénom], T1.Nom, T1.Adresse1, T1.Adresse2, T1.[Code Postal], T1.Ville, T1.[retraité] HAVING T1.[retraité]=True AND Max(T2.[année])> 09 AND Max(T2.[année])< 11 ORDER BY T1.Nom;
J'ai essayé la première, ça fonctionne, que va m'apporter la seconde ? Merci.
Tout dépend des informations dont tu as besoin :
1) Si pas de date => la requête avec DISTINCT est utilisable.
2) S'il faut une date => une requête avec regroupement est obligatoire.
Ensuite la seule différence pourrait être dans la rapidité d'exécution.
Bonjour,
Freeman a écrit :
Le 13/02/2011 21:09, db a écrit :
Le 13/02/2011 20:36, Post Scriptum a écrit :
J'ai essayé les deux, mais elles me donnent un message d'erreur.
L'important c'est que la première fonctionne avec la condition MAX.
Merci à tout les deux.
Effectivement, il y avait une parenthèse en trop dans chacune des
requêtes.
Mille excuses.
db
SELECT DISTINCT T1.Titre, T1.[Prénom], T1.Nom, T1.Adresse1, T1.Adresse2,
T1.[Code Postal], T1.Ville, T1.[retraité]
FROM [adhérents] AS T1 INNER JOIN [adhésion] AS T2
ON T1.refadherent = T2.refadherent
WHERE T1.[retraité]=True AND T2.[année]> 09 AND
T2.[année]< 11
ORDER BY T1.Nom;
SELECT T1.Titre, T1.[Prénom], T1.Nom, T1.Adresse1, T1.Adresse2, T1.[Code Postal], T1.Ville, T1.[retraité], Max(T2.[année]) AS MaxDeannée
FROM [adhérents] AS T1 INNER JOIN [adhésion] AS T2 ON T1.refadherent = T2.refadherent
GROUP BY T1.Titre, T1.[Prénom], T1.Nom, T1.Adresse1, T1.Adresse2, T1.[Code Postal], T1.Ville, T1.[retraité]
HAVING T1.[retraité]=True AND Max(T2.[année])> 09 AND Max(T2.[année])< 11
ORDER BY T1.Nom;
J'ai essayé la première, ça fonctionne, que va m'apporter la seconde ?
Merci.
Tout dépend des informations dont tu as besoin :
1) Si pas de date => la requête avec DISTINCT est utilisable.
2) S'il faut une date => une requête avec regroupement est obligatoire.
Ensuite la seule différence pourrait être dans la rapidité d'exécution.
J'ai essayé les deux, mais elles me donnent un message d'erreur. L'important c'est que la première fonctionne avec la condition MAX. Merci à tout les deux.
Effectivement, il y avait une parenthèse en trop dans chacune des requêtes. Mille excuses.
db
SELECT DISTINCT T1.Titre, T1.[Prénom], T1.Nom, T1.Adresse1, T1.Adresse2, T1.[Code Postal], T1.Ville, T1.[retraité] FROM [adhérents] AS T1 INNER JOIN [adhésion] AS T2 ON T1.refadherent = T2.refadherent WHERE T1.[retraité]=True AND T2.[année]> 09 AND T2.[année]< 11 ORDER BY T1.Nom;
SELECT T1.Titre, T1.[Prénom], T1.Nom, T1.Adresse1, T1.Adresse2, T1.[Code Postal], T1.Ville, T1.[retraité], Max(T2.[année]) AS MaxDeannée FROM [adhérents] AS T1 INNER JOIN [adhésion] AS T2 ON T1.refadherent = T2.refadherent GROUP BY T1.Titre, T1.[Prénom], T1.Nom, T1.Adresse1, T1.Adresse2, T1.[Code Postal], T1.Ville, T1.[retraité] HAVING T1.[retraité]=True AND Max(T2.[année])> 09 AND Max(T2.[année])< 11 ORDER BY T1.Nom;
J'ai essayé la première, ça fonctionne, que va m'apporter la seconde ? Merci.
Tout dépend des informations dont tu as besoin :
1) Si pas de date => la requête avec DISTINCT est utilisable.
2) S'il faut une date => une requête avec regroupement est obligatoire.
Ensuite la seule différence pourrait être dans la rapidité d'exécution.
Post Scriptum
"Michel__D" a écrit dans le message de news: ijdap1$de5$
Bonjour,
Freeman a écrit :
Le 13/02/2011 21:09, db a écrit :
Le 13/02/2011 20:36, Post Scriptum a écrit :
J'ai essayé les deux, mais elles me donnent un message d'erreur. L'important c'est que la première fonctionne avec la condition MAX. Merci à tout les deux.
Effectivement, il y avait une parenthèse en trop dans chacune des requêtes. Mille excuses.
db
SELECT DISTINCT T1.Titre, T1.[Prénom], T1.Nom, T1.Adresse1, T1.Adresse2, T1.[Code Postal], T1.Ville, T1.[retraité] FROM [adhérents] AS T1 INNER JOIN [adhésion] AS T2 ON T1.refadherent = T2.refadherent WHERE T1.[retraité]=True AND T2.[année]> 09 AND T2.[année]< 11 ORDER BY T1.Nom;
SELECT T1.Titre, T1.[Prénom], T1.Nom, T1.Adresse1, T1.Adresse2, T1.[Code Postal], T1.Ville, T1.[retraité], Max(T2.[année]) AS MaxDeannée FROM [adhérents] AS T1 INNER JOIN [adhésion] AS T2 ON T1.refadherent = T2.refadherent GROUP BY T1.Titre, T1.[Prénom], T1.Nom, T1.Adresse1, T1.Adresse2, T1.[Code Postal], T1.Ville, T1.[retraité] HAVING T1.[retraité]=True AND Max(T2.[année])> 09 AND Max(T2.[année])< 11 ORDER BY T1.Nom;
J'ai essayé la première, ça fonctionne, que va m'apporter la seconde ? Merci.
Tout dépend des informations dont tu as besoin :
1) Si pas de date => la requête avec DISTINCT est utilisable.
2) S'il faut une date => une requête avec regroupement est obligatoire.
Ensuite la seule différence pourrait être dans la rapidité d'exécution.
Bien noté, je vais essayé de retenir.
"Michel__D" <Michel.NOSPAM@orange-ft.com.invalid> a écrit dans le message de
news: ijdap1$de5$1@speranza.aioe.org...
Bonjour,
Freeman a écrit :
Le 13/02/2011 21:09, db a écrit :
Le 13/02/2011 20:36, Post Scriptum a écrit :
J'ai essayé les deux, mais elles me donnent un message d'erreur.
L'important c'est que la première fonctionne avec la condition MAX.
Merci à tout les deux.
Effectivement, il y avait une parenthèse en trop dans chacune des
requêtes.
Mille excuses.
db
SELECT DISTINCT T1.Titre, T1.[Prénom], T1.Nom, T1.Adresse1, T1.Adresse2,
T1.[Code Postal], T1.Ville, T1.[retraité]
FROM [adhérents] AS T1 INNER JOIN [adhésion] AS T2
ON T1.refadherent = T2.refadherent
WHERE T1.[retraité]=True AND T2.[année]> 09 AND
T2.[année]< 11
ORDER BY T1.Nom;
SELECT T1.Titre, T1.[Prénom], T1.Nom, T1.Adresse1, T1.Adresse2, T1.[Code
Postal], T1.Ville, T1.[retraité], Max(T2.[année]) AS MaxDeannée
FROM [adhérents] AS T1 INNER JOIN [adhésion] AS T2 ON T1.refadherent =
T2.refadherent
GROUP BY T1.Titre, T1.[Prénom], T1.Nom, T1.Adresse1, T1.Adresse2, T1.[Code
Postal], T1.Ville, T1.[retraité]
HAVING T1.[retraité]=True AND Max(T2.[année])> 09 AND
Max(T2.[année])< 11
ORDER BY T1.Nom;
J'ai essayé la première, ça fonctionne, que va m'apporter la seconde ?
Merci.
Tout dépend des informations dont tu as besoin :
1) Si pas de date => la requête avec DISTINCT est utilisable.
2) S'il faut une date => une requête avec regroupement est obligatoire.
Ensuite la seule différence pourrait être dans la rapidité d'exécution.
"Michel__D" a écrit dans le message de news: ijdap1$de5$
Bonjour,
Freeman a écrit :
Le 13/02/2011 21:09, db a écrit :
Le 13/02/2011 20:36, Post Scriptum a écrit :
J'ai essayé les deux, mais elles me donnent un message d'erreur. L'important c'est que la première fonctionne avec la condition MAX. Merci à tout les deux.
Effectivement, il y avait une parenthèse en trop dans chacune des requêtes. Mille excuses.
db
SELECT DISTINCT T1.Titre, T1.[Prénom], T1.Nom, T1.Adresse1, T1.Adresse2, T1.[Code Postal], T1.Ville, T1.[retraité] FROM [adhérents] AS T1 INNER JOIN [adhésion] AS T2 ON T1.refadherent = T2.refadherent WHERE T1.[retraité]=True AND T2.[année]> 09 AND T2.[année]< 11 ORDER BY T1.Nom;
SELECT T1.Titre, T1.[Prénom], T1.Nom, T1.Adresse1, T1.Adresse2, T1.[Code Postal], T1.Ville, T1.[retraité], Max(T2.[année]) AS MaxDeannée FROM [adhérents] AS T1 INNER JOIN [adhésion] AS T2 ON T1.refadherent = T2.refadherent GROUP BY T1.Titre, T1.[Prénom], T1.Nom, T1.Adresse1, T1.Adresse2, T1.[Code Postal], T1.Ville, T1.[retraité] HAVING T1.[retraité]=True AND Max(T2.[année])> 09 AND Max(T2.[année])< 11 ORDER BY T1.Nom;
J'ai essayé la première, ça fonctionne, que va m'apporter la seconde ? Merci.
Tout dépend des informations dont tu as besoin :
1) Si pas de date => la requête avec DISTINCT est utilisable.
2) S'il faut une date => une requête avec regroupement est obligatoire.
Ensuite la seule différence pourrait être dans la rapidité d'exécution.
Bien noté, je vais essayé de retenir.
Gloops
Freeman a écrit, le 12/02/2011 23:44 :
Bonjour, Comment éviter les doublons dans une requête ? ....................................................................... . Je souhaite convoquer des adhérents ayant été membres ces trois dernières années:
- une table adhérents Avec un Champ : Nom
- une table adhésion Avec un Champ années
Dans les champs -Nom certains ont été membres tous les ans et d'aut res non. ....................................................................... ......
Dans ma requête j'ai demandé regroupement, mais j'ai du oublié au tre chose car ça ne fonctionne pas. D'avance merci !
Bonjour,
Je vais me coller au rôle ingrat du rabat-joie hors sujet. Vous vous éviterez bien des contrariétés en évitant comme la pest e les noms de champs ou de tables comportant des accents.
Ainsi il vaudra mieux une table tabAdherents comportant un champ adhNomAdherent, plutôt qu'une table Adhérents comportant un champ NomAdhérent.
Les accents commencent à passer relativement bien dans les newsgroups, mais dans la structure d'une base de données, je ne m'y risquerais pas trop. Trois ou quatre outils vont avoir été mis au point pour support er les accents donc tout ira bien, et puis quand on va vouloir requêter la base depuis un cinquième outil, le cas ne sera pas prévu, on va se retrouver avec une erreur, différente selon l'outil : plantage du programme, réponse "enregistrement non trouvé", ou autre ...
Les champs comportent de plus en plus souvent des attributs description, dans lesquels on peut en général mettre des accents, et puis si l'out il qui lit ça ne gère pas bien les accents, on va juste avoir un truc un peu moche à l'affichage. Dans le nom de la table ou du champ, si c'est mal géré, on ne trouve pas l'info. Ce n'est quand même pas le mêm e impact.
Freeman a écrit, le 12/02/2011 23:44 :
Bonjour,
Comment éviter les doublons dans une requête ?
....................................................................... .
Je souhaite convoquer des adhérents ayant été membres ces trois
dernières années:
- une table adhérents
Avec un Champ : Nom
- une table adhésion
Avec un Champ années
Dans les champs -Nom certains ont été membres tous les ans et d'aut res non.
....................................................................... ......
Dans ma requête j'ai demandé regroupement, mais j'ai du oublié au tre chose
car ça ne fonctionne pas.
D'avance merci !
Bonjour,
Je vais me coller au rôle ingrat du rabat-joie hors sujet.
Vous vous éviterez bien des contrariétés en évitant comme la pest e les
noms de champs ou de tables comportant des accents.
Ainsi il vaudra mieux une table tabAdherents comportant un champ
adhNomAdherent, plutôt qu'une table Adhérents comportant un champ
NomAdhérent.
Les accents commencent à passer relativement bien dans les newsgroups,
mais dans la structure d'une base de données, je ne m'y risquerais pas
trop. Trois ou quatre outils vont avoir été mis au point pour support er
les accents donc tout ira bien, et puis quand on va vouloir requêter la
base depuis un cinquième outil, le cas ne sera pas prévu, on va se
retrouver avec une erreur, différente selon l'outil : plantage du
programme, réponse "enregistrement non trouvé", ou autre ...
Les champs comportent de plus en plus souvent des attributs description,
dans lesquels on peut en général mettre des accents, et puis si l'out il
qui lit ça ne gère pas bien les accents, on va juste avoir un truc un
peu moche à l'affichage. Dans le nom de la table ou du champ, si c'est
mal géré, on ne trouve pas l'info. Ce n'est quand même pas le mêm e impact.
Bonjour, Comment éviter les doublons dans une requête ? ....................................................................... . Je souhaite convoquer des adhérents ayant été membres ces trois dernières années:
- une table adhérents Avec un Champ : Nom
- une table adhésion Avec un Champ années
Dans les champs -Nom certains ont été membres tous les ans et d'aut res non. ....................................................................... ......
Dans ma requête j'ai demandé regroupement, mais j'ai du oublié au tre chose car ça ne fonctionne pas. D'avance merci !
Bonjour,
Je vais me coller au rôle ingrat du rabat-joie hors sujet. Vous vous éviterez bien des contrariétés en évitant comme la pest e les noms de champs ou de tables comportant des accents.
Ainsi il vaudra mieux une table tabAdherents comportant un champ adhNomAdherent, plutôt qu'une table Adhérents comportant un champ NomAdhérent.
Les accents commencent à passer relativement bien dans les newsgroups, mais dans la structure d'une base de données, je ne m'y risquerais pas trop. Trois ou quatre outils vont avoir été mis au point pour support er les accents donc tout ira bien, et puis quand on va vouloir requêter la base depuis un cinquième outil, le cas ne sera pas prévu, on va se retrouver avec une erreur, différente selon l'outil : plantage du programme, réponse "enregistrement non trouvé", ou autre ...
Les champs comportent de plus en plus souvent des attributs description, dans lesquels on peut en général mettre des accents, et puis si l'out il qui lit ça ne gère pas bien les accents, on va juste avoir un truc un peu moche à l'affichage. Dans le nom de la table ou du champ, si c'est mal géré, on ne trouve pas l'info. Ce n'est quand même pas le mêm e impact.
Gloops
Gloops a écrit, le 05/03/2011 15:44 :
Freeman a écrit, le 12/02/2011 23:44 :
Bonjour, Comment éviter les doublons dans une requête ? ...................................................................... .. Je souhaite convoquer des adhérents ayant été membres ces trois dernières années:
- une table adhérents Avec un Champ : Nom
- une table adhésion Avec un Champ années
Dans les champs -Nom certains ont été membres tous les ans et d'au tres non. ...................................................................... .......
Dans ma requête j'ai demandé regroupement, mais j'ai du oublié a utre chose car ça ne fonctionne pas. D'avance merci !
Bonjour,
Je vais me coller au rôle ingrat du rabat-joie hors sujet. Vous vous éviterez bien des contrariétés en évitant comme la pe ste les noms de champs ou de tables comportant des accents.
Ainsi il vaudra mieux une table tabAdherents comportant un champ adhNomAdherent, plutôt qu'une table Adhérents comportant un champ NomAdhérent.
Les accents commencent à passer relativement bien dans les newsgroups , mais dans la structure d'une base de données, je ne m'y risquerais pa s trop. Trois ou quatre outils vont avoir été mis au point pour suppo rter les accents donc tout ira bien, et puis quand on va vouloir requêter la base depuis un cinquième outil, le cas ne sera pas prévu, on va se retrouver avec une erreur, différente selon l'outil : plantage du programme, réponse "enregistrement non trouvé", ou autre ...
Les champs comportent de plus en plus souvent des attributs description , dans lesquels on peut en général mettre des accents, et puis si l'o util qui lit ça ne gère pas bien les accents, on va juste avoir un truc un peu moche à l'affichage. Dans le nom de la table ou du champ, si c'es t mal géré, on ne trouve pas l'info. Ce n'est quand même pas le mê me impact.
Ah oui n'oublions pas, il y a autre chose qu'il est conseillé d'évite r dans les noms de champs, de tables, de requêtes : ce sont les espaces e t les signes de ponctuation.
Tant qu'on ne met que des lettres tout se passe bien, à certains endroits on peut aussi mettre des chiffres.
Gloops a écrit, le 05/03/2011 15:44 :
Freeman a écrit, le 12/02/2011 23:44 :
Bonjour,
Comment éviter les doublons dans une requête ?
...................................................................... ..
Je souhaite convoquer des adhérents ayant été membres ces trois
dernières années:
- une table adhérents
Avec un Champ : Nom
- une table adhésion
Avec un Champ années
Dans les champs -Nom certains ont été membres tous les ans et d'au tres
non.
...................................................................... .......
Dans ma requête j'ai demandé regroupement, mais j'ai du oublié a utre
chose
car ça ne fonctionne pas.
D'avance merci !
Bonjour,
Je vais me coller au rôle ingrat du rabat-joie hors sujet.
Vous vous éviterez bien des contrariétés en évitant comme la pe ste les
noms de champs ou de tables comportant des accents.
Ainsi il vaudra mieux une table tabAdherents comportant un champ
adhNomAdherent, plutôt qu'une table Adhérents comportant un champ
NomAdhérent.
Les accents commencent à passer relativement bien dans les newsgroups ,
mais dans la structure d'une base de données, je ne m'y risquerais pa s
trop. Trois ou quatre outils vont avoir été mis au point pour suppo rter
les accents donc tout ira bien, et puis quand on va vouloir requêter la
base depuis un cinquième outil, le cas ne sera pas prévu, on va se
retrouver avec une erreur, différente selon l'outil : plantage du
programme, réponse "enregistrement non trouvé", ou autre ...
Les champs comportent de plus en plus souvent des attributs description ,
dans lesquels on peut en général mettre des accents, et puis si l'o util
qui lit ça ne gère pas bien les accents, on va juste avoir un truc un
peu moche à l'affichage. Dans le nom de la table ou du champ, si c'es t
mal géré, on ne trouve pas l'info. Ce n'est quand même pas le mê me impact.
Ah oui n'oublions pas, il y a autre chose qu'il est conseillé d'évite r
dans les noms de champs, de tables, de requêtes : ce sont les espaces e t
les signes de ponctuation.
Tant qu'on ne met que des lettres tout se passe bien, à certains
endroits on peut aussi mettre des chiffres.
Bonjour, Comment éviter les doublons dans une requête ? ...................................................................... .. Je souhaite convoquer des adhérents ayant été membres ces trois dernières années:
- une table adhérents Avec un Champ : Nom
- une table adhésion Avec un Champ années
Dans les champs -Nom certains ont été membres tous les ans et d'au tres non. ...................................................................... .......
Dans ma requête j'ai demandé regroupement, mais j'ai du oublié a utre chose car ça ne fonctionne pas. D'avance merci !
Bonjour,
Je vais me coller au rôle ingrat du rabat-joie hors sujet. Vous vous éviterez bien des contrariétés en évitant comme la pe ste les noms de champs ou de tables comportant des accents.
Ainsi il vaudra mieux une table tabAdherents comportant un champ adhNomAdherent, plutôt qu'une table Adhérents comportant un champ NomAdhérent.
Les accents commencent à passer relativement bien dans les newsgroups , mais dans la structure d'une base de données, je ne m'y risquerais pa s trop. Trois ou quatre outils vont avoir été mis au point pour suppo rter les accents donc tout ira bien, et puis quand on va vouloir requêter la base depuis un cinquième outil, le cas ne sera pas prévu, on va se retrouver avec une erreur, différente selon l'outil : plantage du programme, réponse "enregistrement non trouvé", ou autre ...
Les champs comportent de plus en plus souvent des attributs description , dans lesquels on peut en général mettre des accents, et puis si l'o util qui lit ça ne gère pas bien les accents, on va juste avoir un truc un peu moche à l'affichage. Dans le nom de la table ou du champ, si c'es t mal géré, on ne trouve pas l'info. Ce n'est quand même pas le mê me impact.
Ah oui n'oublions pas, il y a autre chose qu'il est conseillé d'évite r dans les noms de champs, de tables, de requêtes : ce sont les espaces e t les signes de ponctuation.
Tant qu'on ne met que des lettres tout se passe bien, à certains endroits on peut aussi mettre des chiffres.