[WDxx] Logique de conception de requête SQL avec WIndev

Le
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.

Une idée ?

Merci d'avance !
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Gilles TOURREAU
Le #14310591
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...

Cordialement

--
Gilles TOURREAU
Responsable informatique


Société P.O.S
Spécialiste en motoculture depuis + de 30 ans !
http://www.pos.fr
Emmanuel Lecoester
Le #14310581
en construisant ta requete sql ?

"Vito Deruda" 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
Le #14310571
"Vito Deruda" 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 #14310551
Le Mon, 17 Jul 2006 17:23:34 +0200, Vito Deruda é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
Le #14310501
"patrice" news: 44bbb657$0$31784$

"Vito Deruda" 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
Le #14310491
"Emmanuel Lecoester" news: 44bbb5cd$0$21616$
en construisant ta requete sql ?

"Vito Deruda" 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
Le #14310481
"Vito Deruda" 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
Le #14310451
Vito Deruda a pensé très fort :
"patrice" news: 44bbb657$0$31784$

"Vito Deruda" 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
Le #14310441
"patrice" news: 44bc8a69$0$7468$
"Vito Deruda" 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
Le #14310431
"VincentC"
Vito Deruda a pensé très fort :
"patrice" news: 44bbb657$0$31784$

"Vito Deruda" 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.
Publicité
Poster une réponse
Anonyme