Problême pour passer une variable dans un SelectCommand

Bonjour.

J'ai un petit problême assez embetant dans mon code lorsque je veux passer une variable de session dans une requete sql.
Voila, je rentre dans ma variable de session des valeurs stockées en string et toutes entourées de simple quote ( ' ).
Le probleme est que lorsque je fais passer cette variable dans ma requête, je pense que visual entoure toute ma chaine de caractère propre à lui et du coup, ma requête ne fonctionne pas comme je le souhaite.

Voila du code pour etre plus parlant.

Code:

---

1 2 3 4 5 6 7 8 9 10 11

en VB: Session("var")="'006','007','008'"   en Asp.net: <asp:SqlDataSource ID="SqlDataSource1" runat="server" ConnectionString="<%$ ConnectionStrings:test.INFO %>" ProviderName="<%$ ConnectionStrings:test.INFO.ProviderName %>" SelectCommand='SELECT LIBELLE_SECTION FROM SOMA_SECTION WHERE CODE_SECTION IN (:test)'> <SelectParameters> <asp:SessionParameter Name="test" SessionField="var" Type="String" /> </SelectParameters> </asp:SqlDataSource>

---

Je pense que du coup le compilateur lit la requete comme ca:
SELECT LIBELLE_SECTION FROM SOMA_SECTION WHERE CODE_SECTION IN (' '006','007','008' ')

Forcement, la requete n'est plus bonne.

Quelqu'un aurait-il une idée à ce sujet.

En espérant etre clair, je vous souhaite une bonne apres midi

La clause IN est toujours une galère à gérer, je ne connais malheureusement pas de solution pour ce problème. Tu as raison la requête est effectivement évaluée comme si la clause IN n'était qu'une seule et unique valeur et non pas comme une liste de valeurs.
Il y a le même problème lorsque tu souhaites utiliser des paramètres SQL avec une clause IN. Dans ce cas, la solution est soit d'utiliser un paramètre pour chaque valeur du IN, soit de ne pas utiliser de paramètre SQL et de tout concaténer dans la requête directement sous forme de texte.

Tu pourrais construire le SelectCommand sur le Page_Load de ta page.

Et fournir directement la requête construite à ton SqlDataSource

Le IN attend un tableau(table)

On a resolu ce probleme en créant une fonction SQL Serveur qui retourne la table, et dans le IN on fait un (SELECT * FROM nomfonction(@Init))

bon courage

Merci pour vos réponses rapide.

Citation:

---

Tu pourrais construire le SelectCommand sur le Page_Load de ta page

---

J'ai en effet essayé de faire ce de la sorte:

Code:

---

SqlDataSource1.SelectCommand = "SELECT S.LIBELLE_SECTION FROM SOMA_SECTION S WHERE S.CODE_SECTION IN (" + Session("var") + ")"

---

Ce qui devrait mieux marcher

Mais comment puis-je faire pour fournir la requête construite au SqlDataSource ??
Comment marche le SqlDataSource1.Select() ??

Citation:

---

Dans ce cas, la solution est soit d'utiliser un paramètre pour chaque valeur du IN, soit de ne pas utiliser de paramètre SQL et de tout concaténer dans la requête directement sous forme de texte.

---

Je ne sais pas éxactement combien de valeur je vais avoir donc je ne peux ni stocker chaque valeur ni les entrer directement sous forme de texte.

(En fait c'est pour améliorer le temps de réponse de grosses requetes. Je souhaiterais faire une requete qui retourne les valeurs de mon IN et les stocker dans un string pour apres vérifier si ma requete correspond bien a ces valeurs.)

Citation:

---

Envoyé par Off$ide

Le IN attend un tableau(table)

On a resolu ce probleme en créant une fonction SQL Serveur qui retourne la table, et dans le IN on fait un (SELECT * FROM nomfonction(@Init))

bon courage

---

Ta fonction prend en paramètre une liste de valeurs concaténées et renvoie une table temporaire contenant chacune des valeurs ?

Citation:

---

Envoyé par Thetonio007

Mais comment puis-je faire pour fournir la requête construite au SqlDataSource ??

---

Ca marche ça ?

Code:

---

1 2	SqlDataSource1.SqlCommand = ma_string_sql; SqlDataSource1.DataBind()

---

Citation:

---

Envoyé par SaumonAgile

Ta fonction prend en paramètre une liste de valeurs concaténées et renvoie une table temporaire contenant chacune des valeurs ?

---

Exact, voici un extrait :

Code:

---

1 2 3 4 5 6 7

CREATE FUNCTION fn_List ( @Init varchar(50) ) RETURNS @List TABLE ( monInit VARCHAR(50) )

---

Et dans le @Init on envoi les valeurs séparées par des virgules, que l'on decoupe grace au CHARINDEX.

Citation:

---

Envoyé par Off$ide

Exact, voici un extrait :

---

Alors ça c'est futé, ça me plait bien comme solution. :king:
Je n'y avais pas pensé.

si je supprime la définition de ma selectCommand en asp.net et que je défini la commande dans mon code behind en Vb sans pour autant faire de SqlDataSource1.Select() ou de SqlDataSource1.DataBind(), la fonction marche bien. :yaisse2:

Par contre mes requetes sont imposantes et je ne veux pas les voir dans mon code-behind, elles sont très bien la ou elles sont en asp.net mais ca ne marche pas dans ce cas. :(

Citation:

---

On a resolu ce probleme en créant une fonction SQL Serveur qui retourne la table, et dans le IN on fait un (SELECT * FROM nomfonction(@Init))

---

comme mes requetes sont imposantes, je voulais justement limiter le nombre d'acces a la BDD, c'est pourquoi je voulais stocker toutes les valeurs d'une premieres requetes dans un string de la sorte 'val1','val2','val3'... de manière à pouvoir l'insérer dans le IN et de comparer par la suite les valeurs de mes autres requetes avec celles-ci.
--> Moins d'accès BDD du coup et donc temps de réponse moins long.

maintenant, en Asp, ca marchait très bien, mais en .Net, visual veut tellement nous aider que des fois, ca nous met des batons dans les roues. En l'occurence ici.

Il faudrait un moyen pour que le compilateur de rajoute pas automatiquement de quote autour des variables que l'on transmet à la requete.

Citation:

---

Envoyé par SaumonAgile

Alors ça c'est futé, ça me plait bien comme solution. :king:
Je n'y avais pas pensé.

---

A ton service ;)

Un grand merci à Maitre Duss qui m'a donné cette solution :D

Citation:

---

Envoyé par Thetonio007

Il faudrait un moyen pour que le compilateur de rajoute pas automatiquement de quote autour des variables que l'on transmet à la requete.

---

C'est plus compliqué que ça, cela ne vient pas du compilateur. C'est lié au SGBD. Il faut bien comprendre qu'un paramètre SQL n'est pas remplacé caractère à caractère à la place de l'identifiant. Le paramètre est envoyé au SGBD de manière séparée. Le SGBD voit arriver deux objets différents, la requête puis la valeur du paramètre. Il va ensuite formater la valeur pour la faire correspondre au type du paramètre défini (s'il y a besoin de formatage). C'est ce qui te permet de passer des datetime, ou des double sans avoir à les convertir.

Bien ba je vais essayer tout ca.

Mais le but principal était de stocker mes variables dans un string en variable session de manière à vérifier directement à partir de la session et de ne pas être obligé de faire le trajet jusqu'au serveur et la BDD.

Merci quand même pour toutes les infos.
Un grand bravo à vous