[WDxx] Logique de conception de requête SQL avec WIndev
11 réponses
Vito Deruda
Bonjour,
Je tourne en rond depuis une journée sans imaginer encore la logique qui me
permettrait quelquechose qui me semble pourtant "accessible".
J'ai une requête "marequête" ( tiens tiens ).
Un petit module qui s'ouvre et permet de faire des filtres dessus dans une
table ( classique, avec des ou et ect ect )
Evidemment, à chaque rentrée sur ce module je fais la requête sur le fichier
de base, par exemple CLIENTS.
Demande de l'utilisateur : que les recherche successives puissent être
incrémentielles, c'est à dire qu'en allant 2 fois de suite dans le module,
ca affine la recherche ( plutôt que d'avoir deux lignes à entrer, avec un ET
ou un OU )
Donc, il faut que je fasse une requête... Sur elle même. ( qui est une
source de donnees déclarées dans les var globales )
Après des tests de intersect, de l'utilisation de vue, ect ect, je n'arrive
vraiment pas à imaginer comment faire en sachant qu'aparemment on ne peut
pas faire une requête sur elle même.
Je tourne en rond depuis une journée sans imaginer encore la logique qui me permettrait quelquechose qui me semble pourtant "accessible".
J'ai une requête "marequête" ( tiens tiens ). Un petit module qui s'ouvre et permet de faire des filtres dessus dans une table ( classique, avec des ou et ect ect ) Evidemment, à chaque rentrée sur ce module je fais la requête sur le fichier de base, par exemple CLIENTS.
Demande de l'utilisateur : que les recherche successives puissent être incrémentielles, c'est à dire qu'en allant 2 fois de suite dans le module, ca affine la recherche ( plutôt que d'avoir deux lignes à entrer, avec un ET ou un OU )
Donc, il faut que je fasse une requête... Sur elle même. ( qui est une source de donnees déclarées dans les var globales ) Après des tests de intersect, de l'utilisation de vue, ect ect, je n'arrive vraiment pas à imaginer comment faire en sachant qu'aparemment on ne peut pas faire une requête sur elle même.
Une idée ?
Merci d'avance !
Tu sais que tu peux faire des requêtes en utilisant des listes de valeurs du genre :
SELECT * FROM xxxx WHERE yyyy IN {liste}
Tu demandes à l'utilisateur la 1ère fois un paramètre : "Titi"
Tu fais alors : MaRequete.liste = "Titi" AfficheRequete()
Ensuite tu demande un 2ème parametre : "Toto" MaRequete.liste = "Titi" + TAB + "Toto" AfficheRequete()
Sinon tu peux utiliser 2 vues et la fonction HFusionneVue() pour mélanger tes résultats...
Cordialement
-- Gilles TOURREAU Responsable informatique
Société P.O.S Spécialiste en motoculture depuis + de 30 ans ! http://www.pos.fr
Vito Deruda a exprimé avec précision :
Bonjour,
Je tourne en rond depuis une journée sans imaginer encore la logique qui me
permettrait quelquechose qui me semble pourtant "accessible".
J'ai une requête "marequête" ( tiens tiens ).
Un petit module qui s'ouvre et permet de faire des filtres dessus dans une
table ( classique, avec des ou et ect ect )
Evidemment, à chaque rentrée sur ce module je fais la requête sur le fichier
de base, par exemple CLIENTS.
Demande de l'utilisateur : que les recherche successives puissent être
incrémentielles, c'est à dire qu'en allant 2 fois de suite dans le module, ca
affine la recherche ( plutôt que d'avoir deux lignes à entrer, avec un ET ou
un OU )
Donc, il faut que je fasse une requête... Sur elle même. ( qui est une source
de donnees déclarées dans les var globales )
Après des tests de intersect, de l'utilisation de vue, ect ect, je n'arrive
vraiment pas à imaginer comment faire en sachant qu'aparemment on ne peut pas
faire une requête sur elle même.
Une idée ?
Merci d'avance !
Tu sais que tu peux faire des requêtes en utilisant des listes de
valeurs du genre :
SELECT * FROM xxxx WHERE yyyy IN {liste}
Tu demandes à l'utilisateur la 1ère fois un paramètre : "Titi"
Tu fais alors :
MaRequete.liste = "Titi"
AfficheRequete()
Ensuite tu demande un 2ème parametre : "Toto"
MaRequete.liste = "Titi" + TAB + "Toto"
AfficheRequete()
Sinon tu peux utiliser 2 vues et la fonction HFusionneVue() pour
mélanger tes résultats...
Je tourne en rond depuis une journée sans imaginer encore la logique qui me permettrait quelquechose qui me semble pourtant "accessible".
J'ai une requête "marequête" ( tiens tiens ). Un petit module qui s'ouvre et permet de faire des filtres dessus dans une table ( classique, avec des ou et ect ect ) Evidemment, à chaque rentrée sur ce module je fais la requête sur le fichier de base, par exemple CLIENTS.
Demande de l'utilisateur : que les recherche successives puissent être incrémentielles, c'est à dire qu'en allant 2 fois de suite dans le module, ca affine la recherche ( plutôt que d'avoir deux lignes à entrer, avec un ET ou un OU )
Donc, il faut que je fasse une requête... Sur elle même. ( qui est une source de donnees déclarées dans les var globales ) Après des tests de intersect, de l'utilisation de vue, ect ect, je n'arrive vraiment pas à imaginer comment faire en sachant qu'aparemment on ne peut pas faire une requête sur elle même.
Une idée ?
Merci d'avance !
Tu sais que tu peux faire des requêtes en utilisant des listes de valeurs du genre :
SELECT * FROM xxxx WHERE yyyy IN {liste}
Tu demandes à l'utilisateur la 1ère fois un paramètre : "Titi"
Tu fais alors : MaRequete.liste = "Titi" AfficheRequete()
Ensuite tu demande un 2ème parametre : "Toto" MaRequete.liste = "Titi" + TAB + "Toto" AfficheRequete()
Sinon tu peux utiliser 2 vues et la fonction HFusionneVue() pour mélanger tes résultats...
Cordialement
-- Gilles TOURREAU Responsable informatique
Société P.O.S Spécialiste en motoculture depuis + de 30 ans ! http://www.pos.fr
Emmanuel Lecoester
en construisant ta requete sql ?
"Vito Deruda" a écrit dans le message de news:44bbab77$0$18105$
Bonjour,
Je tourne en rond depuis une journée sans imaginer encore la logique qui
me
permettrait quelquechose qui me semble pourtant "accessible".
J'ai une requête "marequête" ( tiens tiens ). Un petit module qui s'ouvre et permet de faire des filtres dessus dans une table ( classique, avec des ou et ect ect ) Evidemment, à chaque rentrée sur ce module je fais la requête sur le
fichier
de base, par exemple CLIENTS.
Demande de l'utilisateur : que les recherche successives puissent être incrémentielles, c'est à dire qu'en allant 2 fois de suite dans le module, ca affine la recherche ( plutôt que d'avoir deux lignes à entrer, avec un
ET
ou un OU )
Donc, il faut que je fasse une requête... Sur elle même. ( qui est une source de donnees déclarées dans les var globales ) Après des tests de intersect, de l'utilisation de vue, ect ect, je
n'arrive
vraiment pas à imaginer comment faire en sachant qu'aparemment on ne peut pas faire une requête sur elle même.
Une idée ?
Merci d'avance !
en construisant ta requete sql ?
"Vito Deruda" <personne@microsoft.com> a écrit dans le message de
news:44bbab77$0$18105$636a55ce@news.free.fr...
Bonjour,
Je tourne en rond depuis une journée sans imaginer encore la logique qui
me
permettrait quelquechose qui me semble pourtant "accessible".
J'ai une requête "marequête" ( tiens tiens ).
Un petit module qui s'ouvre et permet de faire des filtres dessus dans une
table ( classique, avec des ou et ect ect )
Evidemment, à chaque rentrée sur ce module je fais la requête sur le
fichier
de base, par exemple CLIENTS.
Demande de l'utilisateur : que les recherche successives puissent être
incrémentielles, c'est à dire qu'en allant 2 fois de suite dans le module,
ca affine la recherche ( plutôt que d'avoir deux lignes à entrer, avec un
ET
ou un OU )
Donc, il faut que je fasse une requête... Sur elle même. ( qui est une
source de donnees déclarées dans les var globales )
Après des tests de intersect, de l'utilisation de vue, ect ect, je
n'arrive
vraiment pas à imaginer comment faire en sachant qu'aparemment on ne peut
pas faire une requête sur elle même.
"Vito Deruda" a écrit dans le message de news:44bbab77$0$18105$
Bonjour,
Je tourne en rond depuis une journée sans imaginer encore la logique qui
me
permettrait quelquechose qui me semble pourtant "accessible".
J'ai une requête "marequête" ( tiens tiens ). Un petit module qui s'ouvre et permet de faire des filtres dessus dans une table ( classique, avec des ou et ect ect ) Evidemment, à chaque rentrée sur ce module je fais la requête sur le
fichier
de base, par exemple CLIENTS.
Demande de l'utilisateur : que les recherche successives puissent être incrémentielles, c'est à dire qu'en allant 2 fois de suite dans le module, ca affine la recherche ( plutôt que d'avoir deux lignes à entrer, avec un
ET
ou un OU )
Donc, il faut que je fasse une requête... Sur elle même. ( qui est une source de donnees déclarées dans les var globales ) Après des tests de intersect, de l'utilisation de vue, ect ect, je
n'arrive
vraiment pas à imaginer comment faire en sachant qu'aparemment on ne peut pas faire une requête sur elle même.
Une idée ?
Merci d'avance !
patrice
"Vito Deruda" a écrit dans le message de news:44bbab77$0$18105$
Demande de l'utilisateur : que les recherche successives puissent être incrémentielles, c'est à dire qu'en allant 2 fois de suite dans le module, ca affine la recherche ( plutôt que d'avoir deux lignes à entrer, avec un
ET
ou un OU )
construire la requete sql en distanguant le select et le where
mareq=sSelect + sFrom + sWhere et ajouter les conditions à swhere (et mémoriser le précédent)
"Vito Deruda" <personne@microsoft.com> a écrit dans le message de
news:44bbab77$0$18105$636a55ce@news.free.fr...
Demande de l'utilisateur : que les recherche successives puissent être
incrémentielles, c'est à dire qu'en allant 2 fois de suite dans le module,
ca affine la recherche ( plutôt que d'avoir deux lignes à entrer, avec un
ET
ou un OU )
construire la requete sql en distanguant le select et le where
mareq=sSelect + sFrom + sWhere
et ajouter les conditions à swhere (et mémoriser le précédent)
"Vito Deruda" a écrit dans le message de news:44bbab77$0$18105$
Demande de l'utilisateur : que les recherche successives puissent être incrémentielles, c'est à dire qu'en allant 2 fois de suite dans le module, ca affine la recherche ( plutôt que d'avoir deux lignes à entrer, avec un
ET
ou un OU )
construire la requete sql en distanguant le select et le where
mareq=sSelect + sFrom + sWhere et ajouter les conditions à swhere (et mémoriser le précédent)
nwjb
Le Mon, 17 Jul 2006 17:23:34 +0200, Vito Deruda a écrit:
Bonjour,
Je tourne en rond depuis une journée sans imaginer encore la logique qui me permettrait quelquechose qui me semble pourtant "accessible".
J'ai une requête "marequête" ( tiens tiens ). Un petit module qui s'ouvre et permet de faire des filtres dessus dans une table ( classique, avec des ou et ect ect ) Evidemment, à chaque rentrée sur ce module je fais la requête sur le fichier de base, par exemple CLIENTS.
Demande de l'utilisateur : que les recherche successives puissent être incrémentielles, c'est à dire qu'en allant 2 fois de suite dans le module, ca affine la recherche ( plutôt que d'avoir deux lignes à entrer, avec un ET ou un OU )
Donc, il faut que je fasse une requête... Sur elle même. ( qui est une source de donnees déclarées dans les var globales ) Après des tests de intersect, de l'utilisation de vue, ect ect, je n'arrive vraiment pas à imaginer comment faire en sachant qu'aparemment on ne peut pas faire une requête sur elle même.
Une idée ?
Merci d'avance !
J'ai eu un pb du même genre avec des requêtes (insert dans le cas précis) récursives. J'ai fait une fonction récursive (cela marche en WD) et ai utilisé un niveau de récursivité incrémenté automatiquement , et des Halias de la requête de départ.
du genre: numreq++ //(niveau de récursivité) Halias (mareq,"P"+numreq) //créer alias Pnnn ensuite classique ave Hexecuterequete ("P"+numreq) et ...* accès aux champs par {"P"+numreq+".champ"} ne pas oublier les Hannule et le numreq-- à la fin.
Voila résumé rapide.
-- J.Bratières
Enlever paspub pour répondre Please remove paspub when answering
Le Mon, 17 Jul 2006 17:23:34 +0200, Vito Deruda <personne@microsoft.com> a
écrit:
Bonjour,
Je tourne en rond depuis une journée sans imaginer encore la logique qui
me
permettrait quelquechose qui me semble pourtant "accessible".
J'ai une requête "marequête" ( tiens tiens ).
Un petit module qui s'ouvre et permet de faire des filtres dessus dans
une
table ( classique, avec des ou et ect ect )
Evidemment, à chaque rentrée sur ce module je fais la requête sur le
fichier
de base, par exemple CLIENTS.
Demande de l'utilisateur : que les recherche successives puissent être
incrémentielles, c'est à dire qu'en allant 2 fois de suite dans le
module,
ca affine la recherche ( plutôt que d'avoir deux lignes à entrer, avec
un ET
ou un OU )
Donc, il faut que je fasse une requête... Sur elle même. ( qui est une
source de donnees déclarées dans les var globales )
Après des tests de intersect, de l'utilisation de vue, ect ect, je
n'arrive
vraiment pas à imaginer comment faire en sachant qu'aparemment on ne peut
pas faire une requête sur elle même.
Une idée ?
Merci d'avance !
J'ai eu un pb du même genre avec des requêtes (insert dans le cas précis)
récursives.
J'ai fait une fonction récursive (cela marche en WD) et ai utilisé un
niveau
de récursivité incrémenté automatiquement , et des Halias de la requête de
départ.
du genre:
numreq++ //(niveau de récursivité)
Halias (mareq,"P"+numreq) //créer alias Pnnn
ensuite classique ave Hexecuterequete ("P"+numreq) et ...*
accès aux champs par {"P"+numreq+".champ"}
ne pas oublier les Hannule
et le numreq-- à la fin.
Voila résumé rapide.
--
J.Bratières
Enlever paspub pour répondre
Please remove paspub when answering
Le Mon, 17 Jul 2006 17:23:34 +0200, Vito Deruda a écrit:
Bonjour,
Je tourne en rond depuis une journée sans imaginer encore la logique qui me permettrait quelquechose qui me semble pourtant "accessible".
J'ai une requête "marequête" ( tiens tiens ). Un petit module qui s'ouvre et permet de faire des filtres dessus dans une table ( classique, avec des ou et ect ect ) Evidemment, à chaque rentrée sur ce module je fais la requête sur le fichier de base, par exemple CLIENTS.
Demande de l'utilisateur : que les recherche successives puissent être incrémentielles, c'est à dire qu'en allant 2 fois de suite dans le module, ca affine la recherche ( plutôt que d'avoir deux lignes à entrer, avec un ET ou un OU )
Donc, il faut que je fasse une requête... Sur elle même. ( qui est une source de donnees déclarées dans les var globales ) Après des tests de intersect, de l'utilisation de vue, ect ect, je n'arrive vraiment pas à imaginer comment faire en sachant qu'aparemment on ne peut pas faire une requête sur elle même.
Une idée ?
Merci d'avance !
J'ai eu un pb du même genre avec des requêtes (insert dans le cas précis) récursives. J'ai fait une fonction récursive (cela marche en WD) et ai utilisé un niveau de récursivité incrémenté automatiquement , et des Halias de la requête de départ.
du genre: numreq++ //(niveau de récursivité) Halias (mareq,"P"+numreq) //créer alias Pnnn ensuite classique ave Hexecuterequete ("P"+numreq) et ...* accès aux champs par {"P"+numreq+".champ"} ne pas oublier les Hannule et le numreq-- à la fin.
Voila résumé rapide.
-- J.Bratières
Enlever paspub pour répondre Please remove paspub when answering
Vito Deruda
"patrice" a écrit dans le message de news: 44bbb657$0$31784$
"Vito Deruda" a écrit dans le message de news:44bbab77$0$18105$
Demande de l'utilisateur : que les recherche successives puissent être incrémentielles, c'est à dire qu'en allant 2 fois de suite dans le module, ca affine la recherche ( plutôt que d'avoir deux lignes à entrer, avec un
ET
ou un OU )
construire la requete sql en distanguant le select et le where
mareq=sSelect + sFrom + sWhere et ajouter les conditions à swhere (et mémoriser le précédent)
Ca s'applique pas réellement à mon cas.
Imagine : Premier cas, l'utilisateur demande "Ville" = "Paris" ( ils peuvent utiliser les egal contient ect, mais utilisent souvent le = ) Trop de réponse, il l'affine avec "Paris 8 eme".
Cumule des 2 conditions vaut 2 = différents, donc aucun résultat.
"patrice" <patrice_labracherie_nospam@free.fr> a écrit dans le message de
news: 44bbb657$0$31784$626a54ce@news.free.fr...
"Vito Deruda" <personne@microsoft.com> a écrit dans le message de
news:44bbab77$0$18105$636a55ce@news.free.fr...
Demande de l'utilisateur : que les recherche successives puissent être
incrémentielles, c'est à dire qu'en allant 2 fois de suite dans le
module,
ca affine la recherche ( plutôt que d'avoir deux lignes à entrer, avec un
ET
ou un OU )
construire la requete sql en distanguant le select et le where
mareq=sSelect + sFrom + sWhere
et ajouter les conditions à swhere (et mémoriser le précédent)
Ca s'applique pas réellement à mon cas.
Imagine :
Premier cas, l'utilisateur demande "Ville" = "Paris" ( ils peuvent utiliser
les egal contient ect, mais utilisent souvent le = )
Trop de réponse, il l'affine avec "Paris 8 eme".
Cumule des 2 conditions vaut 2 = différents, donc aucun résultat.
"patrice" a écrit dans le message de news: 44bbb657$0$31784$
"Vito Deruda" a écrit dans le message de news:44bbab77$0$18105$
Demande de l'utilisateur : que les recherche successives puissent être incrémentielles, c'est à dire qu'en allant 2 fois de suite dans le module, ca affine la recherche ( plutôt que d'avoir deux lignes à entrer, avec un
ET
ou un OU )
construire la requete sql en distanguant le select et le where
mareq=sSelect + sFrom + sWhere et ajouter les conditions à swhere (et mémoriser le précédent)
Ca s'applique pas réellement à mon cas.
Imagine : Premier cas, l'utilisateur demande "Ville" = "Paris" ( ils peuvent utiliser les egal contient ect, mais utilisent souvent le = ) Trop de réponse, il l'affine avec "Paris 8 eme".
Cumule des 2 conditions vaut 2 = différents, donc aucun résultat.
Vito Deruda
"Emmanuel Lecoester" a écrit dans le message de news: 44bbb5cd$0$21616$
en construisant ta requete sql ?
"Vito Deruda" a écrit dans le message de news:44bbab77$0$18105$
Bonjour,
Je tourne en rond depuis une journée sans imaginer encore la logique qui
me
permettrait quelquechose qui me semble pourtant "accessible".
J'ai une requête "marequête" ( tiens tiens ). Un petit module qui s'ouvre et permet de faire des filtres dessus dans une table ( classique, avec des ou et ect ect ) Evidemment, à chaque rentrée sur ce module je fais la requête sur le
fichier
de base, par exemple CLIENTS.
Demande de l'utilisateur : que les recherche successives puissent être incrémentielles, c'est à dire qu'en allant 2 fois de suite dans le module, ca affine la recherche ( plutôt que d'avoir deux lignes à entrer, avec un
ET
ou un OU )
Donc, il faut que je fasse une requête... Sur elle même. ( qui est une source de donnees déclarées dans les var globales ) Après des tests de intersect, de l'utilisation de vue, ect ect, je
n'arrive
vraiment pas à imaginer comment faire en sachant qu'aparemment on ne peut pas faire une requête sur elle même.
Une idée ?
Merci d'avance !
Comme expliqué à une autre personne, en construisant ma requête je peux me retrouver avec 2 = différents sur la même rubrique.
"Emmanuel Lecoester" <elecoest@netcourrier.com> a écrit dans le message de
news: 44bbb5cd$0$21616$636a55ce@news.free.fr...
en construisant ta requete sql ?
"Vito Deruda" <personne@microsoft.com> a écrit dans le message de
news:44bbab77$0$18105$636a55ce@news.free.fr...
Bonjour,
Je tourne en rond depuis une journée sans imaginer encore la logique qui
me
permettrait quelquechose qui me semble pourtant "accessible".
J'ai une requête "marequête" ( tiens tiens ).
Un petit module qui s'ouvre et permet de faire des filtres dessus dans
une
table ( classique, avec des ou et ect ect )
Evidemment, à chaque rentrée sur ce module je fais la requête sur le
fichier
de base, par exemple CLIENTS.
Demande de l'utilisateur : que les recherche successives puissent être
incrémentielles, c'est à dire qu'en allant 2 fois de suite dans le
module,
ca affine la recherche ( plutôt que d'avoir deux lignes à entrer, avec un
ET
ou un OU )
Donc, il faut que je fasse une requête... Sur elle même. ( qui est une
source de donnees déclarées dans les var globales )
Après des tests de intersect, de l'utilisation de vue, ect ect, je
n'arrive
vraiment pas à imaginer comment faire en sachant qu'aparemment on ne peut
pas faire une requête sur elle même.
Une idée ?
Merci d'avance !
Comme expliqué à une autre personne, en construisant ma requête je peux me
retrouver avec 2 = différents sur la même rubrique.
"Emmanuel Lecoester" a écrit dans le message de news: 44bbb5cd$0$21616$
en construisant ta requete sql ?
"Vito Deruda" a écrit dans le message de news:44bbab77$0$18105$
Bonjour,
Je tourne en rond depuis une journée sans imaginer encore la logique qui
me
permettrait quelquechose qui me semble pourtant "accessible".
J'ai une requête "marequête" ( tiens tiens ). Un petit module qui s'ouvre et permet de faire des filtres dessus dans une table ( classique, avec des ou et ect ect ) Evidemment, à chaque rentrée sur ce module je fais la requête sur le
fichier
de base, par exemple CLIENTS.
Demande de l'utilisateur : que les recherche successives puissent être incrémentielles, c'est à dire qu'en allant 2 fois de suite dans le module, ca affine la recherche ( plutôt que d'avoir deux lignes à entrer, avec un
ET
ou un OU )
Donc, il faut que je fasse une requête... Sur elle même. ( qui est une source de donnees déclarées dans les var globales ) Après des tests de intersect, de l'utilisation de vue, ect ect, je
n'arrive
vraiment pas à imaginer comment faire en sachant qu'aparemment on ne peut pas faire une requête sur elle même.
Une idée ?
Merci d'avance !
Comme expliqué à une autre personne, en construisant ma requête je peux me retrouver avec 2 = différents sur la même rubrique.
patrice
"Vito Deruda" a écrit dans le message de news:44bc8871$0$18107$
Premier cas, l'utilisateur demande "Ville" = "Paris" ( ils peuvent
utiliser
les egal contient ect, mais utilisent souvent le = ) Trop de réponse, il l'affine avec "Paris 8 eme".
Cumule des 2 conditions vaut 2 = différents, donc aucun résultat.
quelquesoit la facon dont tu t'y prend, 2= différend sur une meme rubrique ne donneront jamais deux résultats en tout cas, le cumul des = est justement ce que tu demande.
d'apres ce que tu dit, ville=paris sous entend ville commencant par paris. regarde alors du coté de l'opérateur like
"Vito Deruda" <personne@microsoft.com> a écrit dans le message de
news:44bc8871$0$18107$636a55ce@news.free.fr...
Premier cas, l'utilisateur demande "Ville" = "Paris" ( ils peuvent
utiliser
les egal contient ect, mais utilisent souvent le = )
Trop de réponse, il l'affine avec "Paris 8 eme".
Cumule des 2 conditions vaut 2 = différents, donc aucun résultat.
quelquesoit la facon dont tu t'y prend, 2= différend sur une meme rubrique
ne donneront jamais deux résultats
en tout cas, le cumul des = est justement ce que tu demande.
d'apres ce que tu dit, ville=paris sous entend ville commencant par paris.
regarde alors du coté de l'opérateur like
"Vito Deruda" a écrit dans le message de news:44bc8871$0$18107$
Premier cas, l'utilisateur demande "Ville" = "Paris" ( ils peuvent
utiliser
les egal contient ect, mais utilisent souvent le = ) Trop de réponse, il l'affine avec "Paris 8 eme".
Cumule des 2 conditions vaut 2 = différents, donc aucun résultat.
quelquesoit la facon dont tu t'y prend, 2= différend sur une meme rubrique ne donneront jamais deux résultats en tout cas, le cumul des = est justement ce que tu demande.
d'apres ce que tu dit, ville=paris sous entend ville commencant par paris. regarde alors du coté de l'opérateur like
VincentC
Vito Deruda a pensé très fort :
"patrice" a écrit dans le message de news: 44bbb657$0$31784$
"Vito Deruda" a écrit dans le message de news:44bbab77$0$18105$
Demande de l'utilisateur : que les recherche successives puissent être incrémentielles, c'est à dire qu'en allant 2 fois de suite dans le module, ca affine la recherche ( plutôt que d'avoir deux lignes à entrer, avec un
ET
ou un OU )
construire la requete sql en distanguant le select et le where
mareq=sSelect + sFrom + sWhere et ajouter les conditions à swhere (et mémoriser le précédent)
Ca s'applique pas réellement à mon cas.
Imagine : Premier cas, l'utilisateur demande "Ville" = "Paris" ( ils peuvent utiliser les egal contient ect, mais utilisent souvent le = ) Trop de réponse, il l'affine avec "Paris 8 eme".
Cumule des 2 conditions vaut 2 = différents, donc aucun résultat.
si tu génére le code SQL comme conseillé précédement et que tu relance une requete, cette exemple donnera : (Ville like 'PARIS%') AND (Ville = 'Paris 8 eme')
ou
(Ville like 'PARIS%') AND (Ville like '%Paris 8 eme')
Comme tu empile les filtres tu ne pourras jamais avoir d'incohérence (à part celle demandée par l'utilisateur :
1er rq : departement 92 2em rq : puis ville = paris
=> aucun résultat possible (c qui est tout à fait normal).
VincentC
Vito Deruda a pensé très fort :
"patrice" <patrice_labracherie_nospam@free.fr> a écrit dans le message de
news: 44bbb657$0$31784$626a54ce@news.free.fr...
"Vito Deruda" <personne@microsoft.com> a écrit dans le message de
news:44bbab77$0$18105$636a55ce@news.free.fr...
Demande de l'utilisateur : que les recherche successives puissent être
incrémentielles, c'est à dire qu'en allant 2 fois de suite dans le module,
ca affine la recherche ( plutôt que d'avoir deux lignes à entrer, avec un
ET
ou un OU )
construire la requete sql en distanguant le select et le where
mareq=sSelect + sFrom + sWhere
et ajouter les conditions à swhere (et mémoriser le précédent)
Ca s'applique pas réellement à mon cas.
Imagine :
Premier cas, l'utilisateur demande "Ville" = "Paris" ( ils peuvent utiliser
les egal contient ect, mais utilisent souvent le = )
Trop de réponse, il l'affine avec "Paris 8 eme".
Cumule des 2 conditions vaut 2 = différents, donc aucun résultat.
si tu génére le code SQL comme conseillé précédement et que tu relance
une requete, cette exemple donnera :
(Ville like 'PARIS%')
AND (Ville = 'Paris 8 eme')
ou
(Ville like 'PARIS%')
AND (Ville like '%Paris 8 eme')
Comme tu empile les filtres tu ne pourras jamais avoir d'incohérence (à
part celle demandée par l'utilisateur :
1er rq : departement 92
2em rq : puis ville = paris
=> aucun résultat possible (c qui est tout à fait normal).
"patrice" a écrit dans le message de news: 44bbb657$0$31784$
"Vito Deruda" a écrit dans le message de news:44bbab77$0$18105$
Demande de l'utilisateur : que les recherche successives puissent être incrémentielles, c'est à dire qu'en allant 2 fois de suite dans le module, ca affine la recherche ( plutôt que d'avoir deux lignes à entrer, avec un
ET
ou un OU )
construire la requete sql en distanguant le select et le where
mareq=sSelect + sFrom + sWhere et ajouter les conditions à swhere (et mémoriser le précédent)
Ca s'applique pas réellement à mon cas.
Imagine : Premier cas, l'utilisateur demande "Ville" = "Paris" ( ils peuvent utiliser les egal contient ect, mais utilisent souvent le = ) Trop de réponse, il l'affine avec "Paris 8 eme".
Cumule des 2 conditions vaut 2 = différents, donc aucun résultat.
si tu génére le code SQL comme conseillé précédement et que tu relance une requete, cette exemple donnera : (Ville like 'PARIS%') AND (Ville = 'Paris 8 eme')
ou
(Ville like 'PARIS%') AND (Ville like '%Paris 8 eme')
Comme tu empile les filtres tu ne pourras jamais avoir d'incohérence (à part celle demandée par l'utilisateur :
1er rq : departement 92 2em rq : puis ville = paris
=> aucun résultat possible (c qui est tout à fait normal).
VincentC
Vito Deruda
"patrice" a écrit dans le message de news: 44bc8a69$0$7468$
"Vito Deruda" a écrit dans le message de news:44bc8871$0$18107$
Premier cas, l'utilisateur demande "Ville" = "Paris" ( ils peuvent
utiliser
les egal contient ect, mais utilisent souvent le = ) Trop de réponse, il l'affine avec "Paris 8 eme".
Cumule des 2 conditions vaut 2 = différents, donc aucun résultat.
quelquesoit la facon dont tu t'y prend, 2= différend sur une meme rubrique ne donneront jamais deux résultats en tout cas, le cumul des = est justement ce que tu demande.
d'apres ce que tu dit, ville=paris sous entend ville commencant par paris. regarde alors du coté de l'opérateur like
Sûr. Ma fenêtre propose tous les opérateurs. Libre à l'utilisateur d'utiliser celui qu'il veut sur la rubrique qu'il désire.
S'il veut faire 2 = d'affiler ( ouvrir la fenêtre, puis ville= paris. Fermer la fenêtre, voir les résultats, réouvrir la fenêtre vide, cocher "filtrer sur la base en cours", faire ville=paris 8 eme", valider ). Même si j'utiliserais moi meme effectivement "Contient", ce cheminement ne vaut pas moins qu'un autre.
D'où la nécessité de faire une reqête sur l'existante.
"patrice" <patrice_labracherie_nospam@free.fr> a écrit dans le message de
news: 44bc8a69$0$7468$626a54ce@news.free.fr...
"Vito Deruda" <personne@microsoft.com> a écrit dans le message de
news:44bc8871$0$18107$636a55ce@news.free.fr...
Premier cas, l'utilisateur demande "Ville" = "Paris" ( ils peuvent
utiliser
les egal contient ect, mais utilisent souvent le = )
Trop de réponse, il l'affine avec "Paris 8 eme".
Cumule des 2 conditions vaut 2 = différents, donc aucun résultat.
quelquesoit la facon dont tu t'y prend, 2= différend sur une meme rubrique
ne donneront jamais deux résultats
en tout cas, le cumul des = est justement ce que tu demande.
d'apres ce que tu dit, ville=paris sous entend ville commencant par paris.
regarde alors du coté de l'opérateur like
Sûr. Ma fenêtre propose tous les opérateurs. Libre à l'utilisateur
d'utiliser celui qu'il veut sur la rubrique qu'il désire.
S'il veut faire 2 = d'affiler ( ouvrir la fenêtre, puis ville= paris. Fermer
la fenêtre, voir les résultats, réouvrir la fenêtre vide, cocher "filtrer
sur la base en cours", faire ville=paris 8 eme", valider ).
Même si j'utiliserais moi meme effectivement "Contient", ce cheminement ne
vaut pas moins qu'un autre.
D'où la nécessité de faire une reqête sur l'existante.
"patrice" a écrit dans le message de news: 44bc8a69$0$7468$
"Vito Deruda" a écrit dans le message de news:44bc8871$0$18107$
Premier cas, l'utilisateur demande "Ville" = "Paris" ( ils peuvent
utiliser
les egal contient ect, mais utilisent souvent le = ) Trop de réponse, il l'affine avec "Paris 8 eme".
Cumule des 2 conditions vaut 2 = différents, donc aucun résultat.
quelquesoit la facon dont tu t'y prend, 2= différend sur une meme rubrique ne donneront jamais deux résultats en tout cas, le cumul des = est justement ce que tu demande.
d'apres ce que tu dit, ville=paris sous entend ville commencant par paris. regarde alors du coté de l'opérateur like
Sûr. Ma fenêtre propose tous les opérateurs. Libre à l'utilisateur d'utiliser celui qu'il veut sur la rubrique qu'il désire.
S'il veut faire 2 = d'affiler ( ouvrir la fenêtre, puis ville= paris. Fermer la fenêtre, voir les résultats, réouvrir la fenêtre vide, cocher "filtrer sur la base en cours", faire ville=paris 8 eme", valider ). Même si j'utiliserais moi meme effectivement "Contient", ce cheminement ne vaut pas moins qu'un autre.
D'où la nécessité de faire une reqête sur l'existante.
Vito Deruda
"VincentC" a écrit dans le message de news:
Vito Deruda a pensé très fort :
"patrice" a écrit dans le message de news: 44bbb657$0$31784$
"Vito Deruda" a écrit dans le message de news:44bbab77$0$18105$
Demande de l'utilisateur : que les recherche successives puissent être incrémentielles, c'est à dire qu'en allant 2 fois de suite dans le module, ca affine la recherche ( plutôt que d'avoir deux lignes à entrer, avec un
ET
ou un OU )
construire la requete sql en distanguant le select et le where
mareq=sSelect + sFrom + sWhere et ajouter les conditions à swhere (et mémoriser le précédent)
Ca s'applique pas réellement à mon cas.
Imagine : Premier cas, l'utilisateur demande "Ville" = "Paris" ( ils peuvent utiliser les egal contient ect, mais utilisent souvent le = ) Trop de réponse, il l'affine avec "Paris 8 eme".
Cumule des 2 conditions vaut 2 = différents, donc aucun résultat.
si tu génére le code SQL comme conseillé précédement et que tu relance une requete, cette exemple donnera : (Ville like 'PARIS%') AND (Ville = 'Paris 8 eme')
ou
(Ville like 'PARIS%') AND (Ville like '%Paris 8 eme')
Comme tu empile les filtres tu ne pourras jamais avoir d'incohérence (à part celle demandée par l'utilisateur :
1er rq : departement 92 2em rq : puis ville = paris
=> aucun résultat possible (c qui est tout à fait normal).
VincentC
Je suis d'accord, mais cela est valable seulement pour un enchainement "=" puis "like".
Je ne vais pas remplacer par le code la liberté qu'a l'utilisateur d'utitiliser le "=".
Et je trouve logique que "=" + "=" donne une bonne chose. Si bien sûr, je peux ré exploiter la base de donnée précédente.
"VincentC" <VNO.SPAM_perso@free.Fr> a écrit dans le message de news:
mn.92367d67f3ebbbae.48802@free.Fr...
Vito Deruda a pensé très fort :
"patrice" <patrice_labracherie_nospam@free.fr> a écrit dans le message de
news: 44bbb657$0$31784$626a54ce@news.free.fr...
"Vito Deruda" <personne@microsoft.com> a écrit dans le message de
news:44bbab77$0$18105$636a55ce@news.free.fr...
Demande de l'utilisateur : que les recherche successives puissent être
incrémentielles, c'est à dire qu'en allant 2 fois de suite dans le
module,
ca affine la recherche ( plutôt que d'avoir deux lignes à entrer, avec
un
ET
ou un OU )
construire la requete sql en distanguant le select et le where
mareq=sSelect + sFrom + sWhere
et ajouter les conditions à swhere (et mémoriser le précédent)
Ca s'applique pas réellement à mon cas.
Imagine :
Premier cas, l'utilisateur demande "Ville" = "Paris" ( ils peuvent
utiliser les egal contient ect, mais utilisent souvent le = )
Trop de réponse, il l'affine avec "Paris 8 eme".
Cumule des 2 conditions vaut 2 = différents, donc aucun résultat.
si tu génére le code SQL comme conseillé précédement et que tu relance une
requete, cette exemple donnera :
(Ville like 'PARIS%')
AND (Ville = 'Paris 8 eme')
ou
(Ville like 'PARIS%')
AND (Ville like '%Paris 8 eme')
Comme tu empile les filtres tu ne pourras jamais avoir d'incohérence (à
part celle demandée par l'utilisateur :
1er rq : departement 92
2em rq : puis ville = paris
=> aucun résultat possible (c qui est tout à fait normal).
VincentC
Je suis d'accord, mais cela est valable seulement pour un enchainement "="
puis "like".
Je ne vais pas remplacer par le code la liberté qu'a l'utilisateur
d'utitiliser le "=".
Et je trouve logique que "=" + "=" donne une bonne chose. Si bien sûr, je
peux ré exploiter la base de donnée précédente.
"patrice" a écrit dans le message de news: 44bbb657$0$31784$
"Vito Deruda" a écrit dans le message de news:44bbab77$0$18105$
Demande de l'utilisateur : que les recherche successives puissent être incrémentielles, c'est à dire qu'en allant 2 fois de suite dans le module, ca affine la recherche ( plutôt que d'avoir deux lignes à entrer, avec un
ET
ou un OU )
construire la requete sql en distanguant le select et le where
mareq=sSelect + sFrom + sWhere et ajouter les conditions à swhere (et mémoriser le précédent)
Ca s'applique pas réellement à mon cas.
Imagine : Premier cas, l'utilisateur demande "Ville" = "Paris" ( ils peuvent utiliser les egal contient ect, mais utilisent souvent le = ) Trop de réponse, il l'affine avec "Paris 8 eme".
Cumule des 2 conditions vaut 2 = différents, donc aucun résultat.
si tu génére le code SQL comme conseillé précédement et que tu relance une requete, cette exemple donnera : (Ville like 'PARIS%') AND (Ville = 'Paris 8 eme')
ou
(Ville like 'PARIS%') AND (Ville like '%Paris 8 eme')
Comme tu empile les filtres tu ne pourras jamais avoir d'incohérence (à part celle demandée par l'utilisateur :
1er rq : departement 92 2em rq : puis ville = paris
=> aucun résultat possible (c qui est tout à fait normal).
VincentC
Je suis d'accord, mais cela est valable seulement pour un enchainement "=" puis "like".
Je ne vais pas remplacer par le code la liberté qu'a l'utilisateur d'utitiliser le "=".
Et je trouve logique que "=" + "=" donne une bonne chose. Si bien sûr, je peux ré exploiter la base de donnée précédente.
