[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 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.
c'est valable pour tout enchainement. filtrer un résultat précédent ne fait que retirer des enregistrements suivant un nouveau critère. c'est donc exclusivement l'ajout d'un AND à la clause where de la requête (et dans certain cas, complementé le FROM ) Ce n'est pas à toi de prevoir la recherche suivante de l'utilisateur ou bien de corriger ses opérateurs. Comment veux tu savoir si le "=" de l'utilsateur veut dire "Mot entier" ou "Commence par"
Je reprend ton exemple : si l'utilisateur demande ville <égal à> 'PARIS' il n'aura jamais les villes ègale à 'PARIS 8eme'
si l'utilisateur demande ville <Commence par> 'PARIS' il aura dans les résultats 'PARIS', 'PARIS 8eme', etc ... dans ce cas seulement, il pourra restreindre à 'PARIS' en ajoutant le critère <égal à> 'PARIS' ou en faisant un filtre par valeur rencontrée dans la colonne, ou en cochant "Mot entier" à droite de la ville
Après, tout est dans la mise en forme de l'interface. mais en ce qui concerne la requête, je ne vois toujours pas en quoi ca ne s'applique pas à ton cas.
Avantage de regénéré le code SQL (pas seulement la clause where), c'est l'ajout d'un filtre sur un table liée en optimisant la clause From.
Si tu ne fait une requete que sur une seule table, voir du côté des alias. Personnellement, même sur une seule table, je l'ai toujours fait en uniquement en SQL.
Cdt,
VincentC
Vito Deruda avait énoncé :
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.
c'est valable pour tout enchainement.
filtrer un résultat précédent ne fait que retirer des enregistrements
suivant un nouveau critère. c'est donc exclusivement l'ajout d'un AND à
la clause where de la requête (et dans certain cas, complementé le FROM
)
Ce n'est pas à toi de prevoir la recherche suivante de l'utilisateur ou
bien de corriger ses opérateurs. Comment veux tu savoir si le "=" de
l'utilsateur veut dire "Mot entier" ou "Commence par"
Je reprend ton exemple :
si l'utilisateur demande ville <égal à> 'PARIS'
il n'aura jamais les villes ègale à 'PARIS 8eme'
si l'utilisateur demande ville <Commence par> 'PARIS'
il aura dans les résultats 'PARIS', 'PARIS 8eme', etc ...
dans ce cas seulement, il pourra restreindre à 'PARIS' en ajoutant le
critère <égal à> 'PARIS' ou en faisant un filtre par valeur rencontrée
dans la colonne, ou en cochant "Mot entier" à droite de la ville
Après, tout est dans la mise en forme de l'interface. mais en ce qui
concerne la requête, je ne vois toujours pas en quoi ca ne s'applique
pas à ton cas.
Avantage de regénéré le code SQL (pas seulement la clause where), c'est
l'ajout d'un filtre sur un table liée en optimisant la clause From.
Si tu ne fait une requete que sur une seule table, voir du côté des
alias. Personnellement, même sur une seule table, je l'ai toujours fait
en uniquement en SQL.
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.
c'est valable pour tout enchainement. filtrer un résultat précédent ne fait que retirer des enregistrements suivant un nouveau critère. c'est donc exclusivement l'ajout d'un AND à la clause where de la requête (et dans certain cas, complementé le FROM ) Ce n'est pas à toi de prevoir la recherche suivante de l'utilisateur ou bien de corriger ses opérateurs. Comment veux tu savoir si le "=" de l'utilsateur veut dire "Mot entier" ou "Commence par"
Je reprend ton exemple : si l'utilisateur demande ville <égal à> 'PARIS' il n'aura jamais les villes ègale à 'PARIS 8eme'
si l'utilisateur demande ville <Commence par> 'PARIS' il aura dans les résultats 'PARIS', 'PARIS 8eme', etc ... dans ce cas seulement, il pourra restreindre à 'PARIS' en ajoutant le critère <égal à> 'PARIS' ou en faisant un filtre par valeur rencontrée dans la colonne, ou en cochant "Mot entier" à droite de la ville
Après, tout est dans la mise en forme de l'interface. mais en ce qui concerne la requête, je ne vois toujours pas en quoi ca ne s'applique pas à ton cas.
Avantage de regénéré le code SQL (pas seulement la clause where), c'est l'ajout d'un filtre sur un table liée en optimisant la clause From.
Si tu ne fait une requete que sur une seule table, voir du côté des alias. Personnellement, même sur une seule table, je l'ai toujours fait en uniquement en SQL.
