Je souhaite faire une requête unique pour un formulaire de recherche sur
le web, afin d'éviter des IF/ELSE ou combinatoire exponentiel en
fonction des paramètres.
Pour faire simple au début, je voudrai par exemple faire une recherche
sur un mot qui se trouve dans tous les champs (ou dans un seul: titre,
nom de domaine, ...). Un peu comme google !
Une piste qui bien sûr ne marche pas mais permet de comprendre mon attente:
ma ClauseWhere variable que je passe en paramètre:
ClauseWhere= "WHERE ((Titre LIKE '%' +@MotRech +'%') OR (Descriptif LIKE
'%' +@MotRech +'%'))"
qui pourrait être aussi
ClauseWhere= "WHERE ((Titre LIKE '%' +@MotRech +'%')"
ma requete:
(
@IdSystDiffus tinyint,
@CulLangue char(5),
@MotRech nvarchar(20),
@ClauseWhere nvarchar(2000)
)
AS
SET NOCOUNT ON;
SELECT LienIntTxt.Titre, LienInternets.IdLienInt,LienIntTxt.CulLangue
FROM LienIntTxt
INNER JOIN LienInternets ON LienIntTxt.IdLienInt = LienInternets.IdLienInt
@ClauseWhere;
Est-ce qu'il existe une solution élégante pour résoudre ce problème !?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Patrice
Côté procédure, c'est problématique sauf à faire du SQL dynamique ce qui diminue fortement l'intérêt d'utiliser une procédure stockée.
Quelques pistes : - si le volume est faible, il peut être aussi pratique de filtrer dans l'application cliente (du coup les données peuvent être mises en cache et une modification du filtre n'entraine pas la nécessité de le rafraichir) - en deux étapes : une procédure se charge d'établir la "sélection courante" (en mémorisant les clés), l'autre se base sur cette sélection pour retourner les données (éventuellement tout si pas de sélection), ce qui permet au moins de restreindre le SQL dynamique à une procédure de "mise en place" du filtre. - en utilisant une fonction retournant une table au lieu d'une procédure, la fonction se charge de ce qui est fixe. Comme la fonction peut-être utilisée comme une table, il est possible de lui ajouter des critères.
Je pense que d'autres personnes posteront d'autres suggestions...
Patrice
--
"herve" a écrit dans le message de news:
Bonjour,
Je souhaite faire une requête unique pour un formulaire de recherche sur le web, afin d'éviter des IF/ELSE ou combinatoire exponentiel en fonction des paramètres.
Pour faire simple au début, je voudrai par exemple faire une recherche sur un mot qui se trouve dans tous les champs (ou dans un seul: titre, nom de domaine, ...). Un peu comme google !
Une piste qui bien sûr ne marche pas mais permet de comprendre mon
attente:
ma ClauseWhere variable que je passe en paramètre: ClauseWhere= "WHERE ((Titre LIKE '%' +@MotRech +'%') OR (Descriptif LIKE '%' +@MotRech +'%'))"
qui pourrait être aussi ClauseWhere= "WHERE ((Titre LIKE '%' +@MotRech +'%')"
ma requete: ( @IdSystDiffus tinyint, @CulLangue char(5), @MotRech nvarchar(20), @ClauseWhere nvarchar(2000) ) AS SET NOCOUNT ON;
SELECT LienIntTxt.Titre, LienInternets.IdLienInt,LienIntTxt.CulLangue FROM LienIntTxt INNER JOIN LienInternets ON LienIntTxt.IdLienInt = LienInternets.IdLienInt @ClauseWhere;
Est-ce qu'il existe une solution élégante pour résoudre ce problème !?
Hervé
Côté procédure, c'est problématique sauf à faire du SQL dynamique ce qui
diminue fortement l'intérêt d'utiliser une procédure stockée.
Quelques pistes :
- si le volume est faible, il peut être aussi pratique de filtrer dans
l'application cliente (du coup les données peuvent être mises en cache et
une modification du filtre n'entraine pas la nécessité de le rafraichir)
- en deux étapes : une procédure se charge d'établir la "sélection courante"
(en mémorisant les clés), l'autre se base sur cette sélection pour retourner
les données (éventuellement tout si pas de sélection), ce qui permet au
moins de restreindre le SQL dynamique à une procédure de "mise en place" du
filtre.
- en utilisant une fonction retournant une table au lieu d'une procédure, la
fonction se charge de ce qui est fixe. Comme la fonction peut-être utilisée
comme une table, il est possible de lui ajouter des critères.
Je pense que d'autres personnes posteront d'autres suggestions...
Patrice
--
"herve" <hd-aenlever@9online.fr> a écrit dans le message de
news:OsMKDCRrEHA.2904@TK2MSFTNGP15.phx.gbl...
Bonjour,
Je souhaite faire une requête unique pour un formulaire de recherche sur
le web, afin d'éviter des IF/ELSE ou combinatoire exponentiel en
fonction des paramètres.
Pour faire simple au début, je voudrai par exemple faire une recherche
sur un mot qui se trouve dans tous les champs (ou dans un seul: titre,
nom de domaine, ...). Un peu comme google !
Une piste qui bien sûr ne marche pas mais permet de comprendre mon
attente:
ma ClauseWhere variable que je passe en paramètre:
ClauseWhere= "WHERE ((Titre LIKE '%' +@MotRech +'%') OR (Descriptif LIKE
'%' +@MotRech +'%'))"
qui pourrait être aussi
ClauseWhere= "WHERE ((Titre LIKE '%' +@MotRech +'%')"
ma requete:
(
@IdSystDiffus tinyint,
@CulLangue char(5),
@MotRech nvarchar(20),
@ClauseWhere nvarchar(2000)
)
AS
SET NOCOUNT ON;
SELECT LienIntTxt.Titre, LienInternets.IdLienInt,LienIntTxt.CulLangue
FROM LienIntTxt
INNER JOIN LienInternets ON LienIntTxt.IdLienInt = LienInternets.IdLienInt
@ClauseWhere;
Est-ce qu'il existe une solution élégante pour résoudre ce problème !?
Côté procédure, c'est problématique sauf à faire du SQL dynamique ce qui diminue fortement l'intérêt d'utiliser une procédure stockée.
Quelques pistes : - si le volume est faible, il peut être aussi pratique de filtrer dans l'application cliente (du coup les données peuvent être mises en cache et une modification du filtre n'entraine pas la nécessité de le rafraichir) - en deux étapes : une procédure se charge d'établir la "sélection courante" (en mémorisant les clés), l'autre se base sur cette sélection pour retourner les données (éventuellement tout si pas de sélection), ce qui permet au moins de restreindre le SQL dynamique à une procédure de "mise en place" du filtre. - en utilisant une fonction retournant une table au lieu d'une procédure, la fonction se charge de ce qui est fixe. Comme la fonction peut-être utilisée comme une table, il est possible de lui ajouter des critères.
Je pense que d'autres personnes posteront d'autres suggestions...
Patrice
--
"herve" a écrit dans le message de news:
Bonjour,
Je souhaite faire une requête unique pour un formulaire de recherche sur le web, afin d'éviter des IF/ELSE ou combinatoire exponentiel en fonction des paramètres.
Pour faire simple au début, je voudrai par exemple faire une recherche sur un mot qui se trouve dans tous les champs (ou dans un seul: titre, nom de domaine, ...). Un peu comme google !
Une piste qui bien sûr ne marche pas mais permet de comprendre mon
attente:
ma ClauseWhere variable que je passe en paramètre: ClauseWhere= "WHERE ((Titre LIKE '%' +@MotRech +'%') OR (Descriptif LIKE '%' +@MotRech +'%'))"
qui pourrait être aussi ClauseWhere= "WHERE ((Titre LIKE '%' +@MotRech +'%')"
ma requete: ( @IdSystDiffus tinyint, @CulLangue char(5), @MotRech nvarchar(20), @ClauseWhere nvarchar(2000) ) AS SET NOCOUNT ON;
SELECT LienIntTxt.Titre, LienInternets.IdLienInt,LienIntTxt.CulLangue FROM LienIntTxt INNER JOIN LienInternets ON LienIntTxt.IdLienInt = LienInternets.IdLienInt @ClauseWhere;
Est-ce qu'il existe une solution élégante pour résoudre ce problème !?
Hervé
herve
Bonjour et merci,
Patrice a écrit :
Côté procédure, c'est problématique sauf à faire du SQL dynamique ce qui diminue fortement l'intérêt d'utiliser une procédure stockée.
Quelques pistes : - si le volume est faible, il peut être aussi pratique de filtrer dans l'application cliente (du coup les données peuvent être mises en cache et une modification du filtre n'entraine pas la nécessité de le rafraichir)
Je n'y avai pas pensé mais celà me parait une bonne piste. Quand à la suivante je ne les ai pas bien comprise (et encore moins la dernière pour mon utilisation bien sûr). Si quelqu'un voit d'autres ...
Hervé
- en deux étapes : une procédure se charge d'établir la "sélection courante" (en mémorisant les clés), l'autre se base sur cette sélection pour retourner les données (éventuellement tout si pas de sélection), ce qui permet au moins de restreindre le SQL dynamique à une procédure de "mise en place" du filtre. - en utilisant une fonction retournant une table au lieu d'une procédure, la fonction se charge de ce qui est fixe. Comme la fonction peut-être utilisée comme une table, il est possible de lui ajouter des critères.
Je pense que d'autres personnes posteront d'autres suggestions...
Patrice
Bonjour et merci,
Patrice a écrit :
Côté procédure, c'est problématique sauf à faire du SQL dynamique ce qui
diminue fortement l'intérêt d'utiliser une procédure stockée.
Quelques pistes :
- si le volume est faible, il peut être aussi pratique de filtrer dans
l'application cliente (du coup les données peuvent être mises en cache et
une modification du filtre n'entraine pas la nécessité de le rafraichir)
Je n'y avai pas pensé mais celà me parait une bonne piste.
Quand à la suivante je ne les ai pas bien comprise (et encore moins la
dernière pour mon utilisation bien sûr).
Si quelqu'un voit d'autres ...
Hervé
- en deux étapes : une procédure se charge d'établir la "sélection courante"
(en mémorisant les clés), l'autre se base sur cette sélection pour retourner
les données (éventuellement tout si pas de sélection), ce qui permet au
moins de restreindre le SQL dynamique à une procédure de "mise en place" du
filtre.
- en utilisant une fonction retournant une table au lieu d'une procédure, la
fonction se charge de ce qui est fixe. Comme la fonction peut-être utilisée
comme une table, il est possible de lui ajouter des critères.
Je pense que d'autres personnes posteront d'autres suggestions...
Côté procédure, c'est problématique sauf à faire du SQL dynamique ce qui diminue fortement l'intérêt d'utiliser une procédure stockée.
Quelques pistes : - si le volume est faible, il peut être aussi pratique de filtrer dans l'application cliente (du coup les données peuvent être mises en cache et une modification du filtre n'entraine pas la nécessité de le rafraichir)
Je n'y avai pas pensé mais celà me parait une bonne piste. Quand à la suivante je ne les ai pas bien comprise (et encore moins la dernière pour mon utilisation bien sûr). Si quelqu'un voit d'autres ...
Hervé
- en deux étapes : une procédure se charge d'établir la "sélection courante" (en mémorisant les clés), l'autre se base sur cette sélection pour retourner les données (éventuellement tout si pas de sélection), ce qui permet au moins de restreindre le SQL dynamique à une procédure de "mise en place" du filtre. - en utilisant une fonction retournant une table au lieu d'une procédure, la fonction se charge de ce qui est fixe. Comme la fonction peut-être utilisée comme une table, il est possible de lui ajouter des critères.
Je pense que d'autres personnes posteront d'autres suggestions...
Patrice
Nicolas LETULLIER
Une autre piste serait d'utiliser un ou plusieurs autres paramètres de la SP pour indiquer dans quels champs rechercher, et construire du SQL fixe
Exemple
CREATE PROCEDURE RechercheTexte @MotRech nvarchar(20), @ChercheDansTitre bit, @ChercheDansDesc bit AS SELECT LienIntTxt.Titre, LienInternets.IdLienInt,LienIntTxt.CulLangue FROM LienIntTxt INNER JOIN LienInternets ON LienIntTxt.IdLienInt = LienInternets.IdLienInt WHERE ((@ChercheDansTitre = 0) OR ((@ChercheDansTitre = 1) AND (Titre LIKE '%' + @MotRech + '%'))) AND ((@ChercheDansDesc = 0) OR ((@ChercheDansDesc = 1) AND (Descriptif LIKE '%' + @MotRech + '%'))) ...
"Patrice" a écrit dans le message de news:
Côté procédure, c'est problématique sauf à faire du SQL dynamique ce qui diminue fortement l'intérêt d'utiliser une procédure stockée.
Quelques pistes : - si le volume est faible, il peut être aussi pratique de filtrer dans l'application cliente (du coup les données peuvent être mises en cache et une modification du filtre n'entraine pas la nécessité de le rafraichir) - en deux étapes : une procédure se charge d'établir la "sélection courante" (en mémorisant les clés), l'autre se base sur cette sélection pour retourner les données (éventuellement tout si pas de sélection), ce qui permet au moins de restreindre le SQL dynamique à une procédure de "mise en place" du filtre. - en utilisant une fonction retournant une table au lieu d'une procédure, la fonction se charge de ce qui est fixe. Comme la fonction peut-être utilisée comme une table, il est possible de lui ajouter des critères.
Je pense que d'autres personnes posteront d'autres suggestions...
Patrice
--
"herve" a écrit dans le message de news:
Bonjour,
Je souhaite faire une requête unique pour un formulaire de recherche sur le web, afin d'éviter des IF/ELSE ou combinatoire exponentiel en fonction des paramètres.
Pour faire simple au début, je voudrai par exemple faire une recherche sur un mot qui se trouve dans tous les champs (ou dans un seul: titre, nom de domaine, ...). Un peu comme google !
Une piste qui bien sûr ne marche pas mais permet de comprendre mon
attente:
ma ClauseWhere variable que je passe en paramètre: ClauseWhere= "WHERE ((Titre LIKE '%' +@MotRech +'%') OR (Descriptif LIKE '%' +@MotRech +'%'))"
qui pourrait être aussi ClauseWhere= "WHERE ((Titre LIKE '%' +@MotRech +'%')"
ma requete: ( @IdSystDiffus tinyint, @CulLangue char(5), @MotRech nvarchar(20), @ClauseWhere nvarchar(2000) ) AS SET NOCOUNT ON;
SELECT LienIntTxt.Titre, LienInternets.IdLienInt,LienIntTxt.CulLangue FROM LienIntTxt INNER JOIN LienInternets ON LienIntTxt.IdLienInt = LienInternets.IdLienInt @ClauseWhere;
Est-ce qu'il existe une solution élégante pour résoudre ce problème !?
Hervé
Une autre piste serait d'utiliser un ou plusieurs autres paramètres de la SP
pour indiquer dans quels champs rechercher, et construire du SQL fixe
Exemple
CREATE PROCEDURE RechercheTexte @MotRech nvarchar(20), @ChercheDansTitre
bit, @ChercheDansDesc bit
AS
SELECT LienIntTxt.Titre, LienInternets.IdLienInt,LienIntTxt.CulLangue
FROM LienIntTxt
INNER JOIN LienInternets ON LienIntTxt.IdLienInt = LienInternets.IdLienInt
WHERE
((@ChercheDansTitre = 0) OR ((@ChercheDansTitre = 1) AND (Titre LIKE '%'
+ @MotRech + '%')))
AND
((@ChercheDansDesc = 0) OR ((@ChercheDansDesc = 1) AND (Descriptif LIKE
'%' + @MotRech + '%')))
...
"Patrice" <nobody@nowhere.com> a écrit dans le message de news:
OzfnA0RrEHA.3080@TK2MSFTNGP15.phx.gbl...
Côté procédure, c'est problématique sauf à faire du SQL dynamique ce qui
diminue fortement l'intérêt d'utiliser une procédure stockée.
Quelques pistes :
- si le volume est faible, il peut être aussi pratique de filtrer dans
l'application cliente (du coup les données peuvent être mises en cache et
une modification du filtre n'entraine pas la nécessité de le rafraichir)
- en deux étapes : une procédure se charge d'établir la "sélection
courante"
(en mémorisant les clés), l'autre se base sur cette sélection pour
retourner
les données (éventuellement tout si pas de sélection), ce qui permet au
moins de restreindre le SQL dynamique à une procédure de "mise en place"
du
filtre.
- en utilisant une fonction retournant une table au lieu d'une procédure,
la
fonction se charge de ce qui est fixe. Comme la fonction peut-être
utilisée
comme une table, il est possible de lui ajouter des critères.
Je pense que d'autres personnes posteront d'autres suggestions...
Patrice
--
"herve" <hd-aenlever@9online.fr> a écrit dans le message de
news:OsMKDCRrEHA.2904@TK2MSFTNGP15.phx.gbl...
Bonjour,
Je souhaite faire une requête unique pour un formulaire de recherche sur
le web, afin d'éviter des IF/ELSE ou combinatoire exponentiel en
fonction des paramètres.
Pour faire simple au début, je voudrai par exemple faire une recherche
sur un mot qui se trouve dans tous les champs (ou dans un seul: titre,
nom de domaine, ...). Un peu comme google !
Une piste qui bien sûr ne marche pas mais permet de comprendre mon
attente:
ma ClauseWhere variable que je passe en paramètre:
ClauseWhere= "WHERE ((Titre LIKE '%' +@MotRech +'%') OR (Descriptif LIKE
'%' +@MotRech +'%'))"
qui pourrait être aussi
ClauseWhere= "WHERE ((Titre LIKE '%' +@MotRech +'%')"
ma requete:
(
@IdSystDiffus tinyint,
@CulLangue char(5),
@MotRech nvarchar(20),
@ClauseWhere nvarchar(2000)
)
AS
SET NOCOUNT ON;
SELECT LienIntTxt.Titre, LienInternets.IdLienInt,LienIntTxt.CulLangue
FROM LienIntTxt
INNER JOIN LienInternets ON LienIntTxt.IdLienInt =
LienInternets.IdLienInt
@ClauseWhere;
Est-ce qu'il existe une solution élégante pour résoudre ce problème !?
Une autre piste serait d'utiliser un ou plusieurs autres paramètres de la SP pour indiquer dans quels champs rechercher, et construire du SQL fixe
Exemple
CREATE PROCEDURE RechercheTexte @MotRech nvarchar(20), @ChercheDansTitre bit, @ChercheDansDesc bit AS SELECT LienIntTxt.Titre, LienInternets.IdLienInt,LienIntTxt.CulLangue FROM LienIntTxt INNER JOIN LienInternets ON LienIntTxt.IdLienInt = LienInternets.IdLienInt WHERE ((@ChercheDansTitre = 0) OR ((@ChercheDansTitre = 1) AND (Titre LIKE '%' + @MotRech + '%'))) AND ((@ChercheDansDesc = 0) OR ((@ChercheDansDesc = 1) AND (Descriptif LIKE '%' + @MotRech + '%'))) ...
"Patrice" a écrit dans le message de news:
Côté procédure, c'est problématique sauf à faire du SQL dynamique ce qui diminue fortement l'intérêt d'utiliser une procédure stockée.
Quelques pistes : - si le volume est faible, il peut être aussi pratique de filtrer dans l'application cliente (du coup les données peuvent être mises en cache et une modification du filtre n'entraine pas la nécessité de le rafraichir) - en deux étapes : une procédure se charge d'établir la "sélection courante" (en mémorisant les clés), l'autre se base sur cette sélection pour retourner les données (éventuellement tout si pas de sélection), ce qui permet au moins de restreindre le SQL dynamique à une procédure de "mise en place" du filtre. - en utilisant une fonction retournant une table au lieu d'une procédure, la fonction se charge de ce qui est fixe. Comme la fonction peut-être utilisée comme une table, il est possible de lui ajouter des critères.
Je pense que d'autres personnes posteront d'autres suggestions...
Patrice
--
"herve" a écrit dans le message de news:
Bonjour,
Je souhaite faire une requête unique pour un formulaire de recherche sur le web, afin d'éviter des IF/ELSE ou combinatoire exponentiel en fonction des paramètres.
Pour faire simple au début, je voudrai par exemple faire une recherche sur un mot qui se trouve dans tous les champs (ou dans un seul: titre, nom de domaine, ...). Un peu comme google !
Une piste qui bien sûr ne marche pas mais permet de comprendre mon
attente:
ma ClauseWhere variable que je passe en paramètre: ClauseWhere= "WHERE ((Titre LIKE '%' +@MotRech +'%') OR (Descriptif LIKE '%' +@MotRech +'%'))"
qui pourrait être aussi ClauseWhere= "WHERE ((Titre LIKE '%' +@MotRech +'%')"
ma requete: ( @IdSystDiffus tinyint, @CulLangue char(5), @MotRech nvarchar(20), @ClauseWhere nvarchar(2000) ) AS SET NOCOUNT ON;
SELECT LienIntTxt.Titre, LienInternets.IdLienInt,LienIntTxt.CulLangue FROM LienIntTxt INNER JOIN LienInternets ON LienIntTxt.IdLienInt = LienInternets.IdLienInt @ClauseWhere;
Est-ce qu'il existe une solution élégante pour résoudre ce problème !?
Hervé
herve
Nicolas LETULLIER a écrit :
Une autre piste serait d'utiliser un ou plusieurs autres paramètres de la SP pour indiquer dans quels champs rechercher, et construire du SQL fixe
Exemple
CREATE PROCEDURE RechercheTexte @MotRech nvarchar(20), @ChercheDansTitre bit, @ChercheDansDesc bit AS SELECT LienIntTxt.Titre, LienInternets.IdLienInt,LienIntTxt.CulLangue FROM LienIntTxt INNER JOIN LienInternets ON LienIntTxt.IdLienInt = LienInternets.IdLienInt WHERE ((@ChercheDansTitre = 0) OR ((@ChercheDansTitre = 1) AND (Titre LIKE '%' + @MotRech + '%'))) AND ((@ChercheDansDesc = 0) OR ((@ChercheDansDesc = 1) AND (Descriptif LIKE '%' + @MotRech + '%'))) ...
Super,
Je n'ai pas rajoutté tous les paramètres mais ça l'air d'etre la meilleur piste.
petite rectification (qui va aussi limiter la combinatoire puisque je teste au moins 4 champs) en enlevant les @Cherche.. = 0 En plus pour avoir progressivement tous les champs, j'ai mis un OU logique
AND ( (@ChercheDansTitre = 1) AND (Titre LIKE '%' + @MotRech + '%') OR (@ChercheDansDesc = 1) AND (Descriptif LIKE '%' + @MotRech + '%') );
Hervé
Nicolas LETULLIER a écrit :
Une autre piste serait d'utiliser un ou plusieurs autres paramètres de la SP
pour indiquer dans quels champs rechercher, et construire du SQL fixe
Exemple
CREATE PROCEDURE RechercheTexte @MotRech nvarchar(20), @ChercheDansTitre
bit, @ChercheDansDesc bit
AS
SELECT LienIntTxt.Titre, LienInternets.IdLienInt,LienIntTxt.CulLangue
FROM LienIntTxt
INNER JOIN LienInternets ON LienIntTxt.IdLienInt = LienInternets.IdLienInt
WHERE
((@ChercheDansTitre = 0) OR ((@ChercheDansTitre = 1) AND (Titre LIKE '%'
+ @MotRech + '%')))
AND
((@ChercheDansDesc = 0) OR ((@ChercheDansDesc = 1) AND (Descriptif LIKE
'%' + @MotRech + '%')))
...
Super,
Je n'ai pas rajoutté tous les paramètres mais ça l'air d'etre la
meilleur piste.
petite rectification (qui va aussi limiter la combinatoire puisque je
teste au moins 4 champs) en enlevant les @Cherche.. = 0
En plus pour avoir progressivement tous les champs, j'ai mis un OU logique
AND ( (@ChercheDansTitre = 1) AND (Titre LIKE '%' + @MotRech + '%')
OR (@ChercheDansDesc = 1) AND (Descriptif LIKE '%' + @MotRech + '%') );
Une autre piste serait d'utiliser un ou plusieurs autres paramètres de la SP pour indiquer dans quels champs rechercher, et construire du SQL fixe
Exemple
CREATE PROCEDURE RechercheTexte @MotRech nvarchar(20), @ChercheDansTitre bit, @ChercheDansDesc bit AS SELECT LienIntTxt.Titre, LienInternets.IdLienInt,LienIntTxt.CulLangue FROM LienIntTxt INNER JOIN LienInternets ON LienIntTxt.IdLienInt = LienInternets.IdLienInt WHERE ((@ChercheDansTitre = 0) OR ((@ChercheDansTitre = 1) AND (Titre LIKE '%' + @MotRech + '%'))) AND ((@ChercheDansDesc = 0) OR ((@ChercheDansDesc = 1) AND (Descriptif LIKE '%' + @MotRech + '%'))) ...
Super,
Je n'ai pas rajoutté tous les paramètres mais ça l'air d'etre la meilleur piste.
petite rectification (qui va aussi limiter la combinatoire puisque je teste au moins 4 champs) en enlevant les @Cherche.. = 0 En plus pour avoir progressivement tous les champs, j'ai mis un OU logique
AND ( (@ChercheDansTitre = 1) AND (Titre LIKE '%' + @MotRech + '%') OR (@ChercheDansDesc = 1) AND (Descriptif LIKE '%' + @MotRech + '%') );
Hervé
Mel
Bonjour, J'ai déjà fait une clause where en utilisant un CASE qui me permettait de tenir compte d'une valeur reçue en paramètre. Si je comprends bien ce que tu veux faire, tu pourrais utiliser quelque chose de semblable mais adapté en fonction de tes besoins: select champ1,champ2 from table1 where (DateImpression between @DateDebut and @DateFin) and champ2 = (case when @BurSPG <> '' then (@BurSPG) else (champ2) end) )
Mel
-----Message d'origine----- Bonjour,
Je souhaite faire une requête unique pour un formulaire
de recherche sur
le web, afin d'éviter des IF/ELSE ou combinatoire
exponentiel en
fonction des paramètres.
Pour faire simple au début, je voudrai par exemple faire
une recherche
sur un mot qui se trouve dans tous les champs (ou dans
un seul: titre,
nom de domaine, ...). Un peu comme google !
Une piste qui bien sûr ne marche pas mais permet de
comprendre mon attente:
ma ClauseWhere variable que je passe en paramètre: ClauseWhere= "WHERE ((Titre LIKE '%' +@MotRech +'%') OR
(Descriptif LIKE
'%' +@MotRech +'%'))"
qui pourrait être aussi ClauseWhere= "WHERE ((Titre LIKE '%' +@MotRech +'%')"
ma requete: ( @IdSystDiffus tinyint, @CulLangue char(5), @MotRech nvarchar(20), @ClauseWhere nvarchar(2000) ) AS SET NOCOUNT ON;
SELECT LienIntTxt.Titre,
LienInternets.IdLienInt,LienIntTxt.CulLangue
FROM LienIntTxt INNER JOIN LienInternets ON LienIntTxt.IdLienInt =
LienInternets.IdLienInt
@ClauseWhere;
Est-ce qu'il existe une solution élégante pour résoudre
ce problème !?
Hervé .
Bonjour,
J'ai déjà fait une clause where en utilisant un CASE qui
me permettait de tenir compte d'une valeur reçue en
paramètre. Si je comprends bien ce que tu veux faire, tu
pourrais utiliser quelque chose de semblable mais adapté
en fonction de tes besoins:
select champ1,champ2
from table1
where (DateImpression between @DateDebut and @DateFin)
and champ2 =
(case
when @BurSPG <> ''
then (@BurSPG)
else (champ2)
end) )
Mel
-----Message d'origine-----
Bonjour,
Je souhaite faire une requête unique pour un formulaire
de recherche sur
le web, afin d'éviter des IF/ELSE ou combinatoire
exponentiel en
fonction des paramètres.
Pour faire simple au début, je voudrai par exemple faire
une recherche
sur un mot qui se trouve dans tous les champs (ou dans
un seul: titre,
nom de domaine, ...). Un peu comme google !
Une piste qui bien sûr ne marche pas mais permet de
comprendre mon attente:
ma ClauseWhere variable que je passe en paramètre:
ClauseWhere= "WHERE ((Titre LIKE '%' +@MotRech +'%') OR
(Descriptif LIKE
'%' +@MotRech +'%'))"
qui pourrait être aussi
ClauseWhere= "WHERE ((Titre LIKE '%' +@MotRech +'%')"
ma requete:
(
@IdSystDiffus tinyint,
@CulLangue char(5),
@MotRech nvarchar(20),
@ClauseWhere nvarchar(2000)
)
AS
SET NOCOUNT ON;
SELECT LienIntTxt.Titre,
LienInternets.IdLienInt,LienIntTxt.CulLangue
FROM LienIntTxt
INNER JOIN LienInternets ON LienIntTxt.IdLienInt =
LienInternets.IdLienInt
@ClauseWhere;
Est-ce qu'il existe une solution élégante pour résoudre
Bonjour, J'ai déjà fait une clause where en utilisant un CASE qui me permettait de tenir compte d'une valeur reçue en paramètre. Si je comprends bien ce que tu veux faire, tu pourrais utiliser quelque chose de semblable mais adapté en fonction de tes besoins: select champ1,champ2 from table1 where (DateImpression between @DateDebut and @DateFin) and champ2 = (case when @BurSPG <> '' then (@BurSPG) else (champ2) end) )
Mel
-----Message d'origine----- Bonjour,
Je souhaite faire une requête unique pour un formulaire
de recherche sur
le web, afin d'éviter des IF/ELSE ou combinatoire
exponentiel en
fonction des paramètres.
Pour faire simple au début, je voudrai par exemple faire
une recherche
sur un mot qui se trouve dans tous les champs (ou dans
un seul: titre,
nom de domaine, ...). Un peu comme google !
Une piste qui bien sûr ne marche pas mais permet de
comprendre mon attente:
ma ClauseWhere variable que je passe en paramètre: ClauseWhere= "WHERE ((Titre LIKE '%' +@MotRech +'%') OR
(Descriptif LIKE
'%' +@MotRech +'%'))"
qui pourrait être aussi ClauseWhere= "WHERE ((Titre LIKE '%' +@MotRech +'%')"
ma requete: ( @IdSystDiffus tinyint, @CulLangue char(5), @MotRech nvarchar(20), @ClauseWhere nvarchar(2000) ) AS SET NOCOUNT ON;
SELECT LienIntTxt.Titre,
LienInternets.IdLienInt,LienIntTxt.CulLangue
FROM LienIntTxt INNER JOIN LienInternets ON LienIntTxt.IdLienInt =
LienInternets.IdLienInt
@ClauseWhere;
Est-ce qu'il existe une solution élégante pour résoudre
ce problème !?
Hervé .
herve
Mel a écrit :
Bonjour, J'ai déjà fait une clause where en utilisant un CASE qui me permettait de tenir compte d'une valeur reçue en paramètre. Si je comprends bien ce que tu veux faire, tu pourrais utiliser quelque chose de semblable mais adapté en fonction de tes besoins: select champ1,champ2 from table1 where (DateImpression between @DateDebut and @DateFin) and champ2 > (case when @BurSPG <> '' then (@BurSPG) else (champ2) end) )
Mel
Bonsoir,
Pas bête non plus et moi qui pensait que celà allait être dur de trouver une solution. Et voilà qu'elles fusent encore merci hervé
Mel a écrit :
Bonjour,
J'ai déjà fait une clause where en utilisant un CASE qui
me permettait de tenir compte d'une valeur reçue en
paramètre. Si je comprends bien ce que tu veux faire, tu
pourrais utiliser quelque chose de semblable mais adapté
en fonction de tes besoins:
select champ1,champ2
from table1
where (DateImpression between @DateDebut and @DateFin)
and champ2 > (case
when @BurSPG <> ''
then (@BurSPG)
else (champ2)
end) )
Mel
Bonsoir,
Pas bête non plus et moi qui pensait que celà allait être dur de trouver
une solution.
Et voilà qu'elles fusent
encore merci
hervé
Bonjour, J'ai déjà fait une clause where en utilisant un CASE qui me permettait de tenir compte d'une valeur reçue en paramètre. Si je comprends bien ce que tu veux faire, tu pourrais utiliser quelque chose de semblable mais adapté en fonction de tes besoins: select champ1,champ2 from table1 where (DateImpression between @DateDebut and @DateFin) and champ2 > (case when @BurSPG <> '' then (@BurSPG) else (champ2) end) )
Mel
Bonsoir,
Pas bête non plus et moi qui pensait que celà allait être dur de trouver une solution. Et voilà qu'elles fusent encore merci hervé