Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Windows Windows Serveur SQL Serveur @@SPID SQL Server ET application Web en .NET

@@SPID SQL Server ET application Web en .NET

16 réponses
Avatar
Zim
Bonjour à tous,

ma question est la suivante : est-il possible dans SQL Server d'identifier
une connexion de manière unique ?
Je m'explique.

Afin de simplifier mes procédures stockées qui nécessite un nombre
indeterminés de paramètres
(comprenez par là qu'il faudrait que je passe un tableau de paramètres), je
me vois dans l'obligation de créer une
table temporaire qui fait office de tableau.

J'ai donc pensé (ça m'arrive), plutôt que de créer une table à chaque fois,
j'en crée une définitive dans laquelle
il y aura un champs qui me servira à détécter ma connexion. Pour cela
j'utilise la valeur @@SPID.

En gros, le fonctionnement est le suivant: imaginons qu'un utilisateur
souhaite avoir le total de n factures,
il se crée dans cette table les n identifiants de factures associées au
@@SPID du client en question (en espérant être clair).
Ainsi, dans mes procédures stockées, il ne me reste qu'à faire une jointure
sur cette table avec comme paramètre le @@SPID :

SELECT SUM(montant)
FROM facture JOIN tableParam JOIN facture.id ON tableParam.idFacture AND
tableParam.spid = @@SPID
(c'est simple et rapide).

Par contre, mon problème est le suivant. Dans mon application web (en .NET),
si un utilisateur attaquent la base alors qu'un autre utilisateur y est déjà
présent,
lors du rafraichissement des données, le premier utilisateur "récupère" les
données de second, autrement dit, la connexion est la même !
Effectivement, le @@SPID du second utilisateur devient celui de premier.

J'ai donc pensé forcer le pooling de la connexion à 'false' en espérant que
la situation s'arrange, mais rien y fait.
J'ai conscience de ne pas avoir été très clair, si quelqu'un pouvait tout de
même m'aider, je le remercie par avance.

Zim.
Signaler un problème avec ce contenu

6 réponses

Supprimer
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
1 2
Avatar
Zim
Bonsoir,

pour te répondre franchement, le soucis que j'ai avec les IN( x paramètres )
est qu'il faut générer la requetes dynamiquement dans le code :
SQL = "SELECT * FROM table WHERE machin IN ("
foreach(string facture in collectionFacture)
SQL += facture +","
etc ...
D'autre part, je ne peux pas avoir de procédure stockées (qui accélère les
traitements).

D'où ma question : ai-je un problème de design de ma base ? et si oui,
comment y remédier.

Merci d'avoir pris le temps de me répondre.

Amicalement, Zim.

"Thomas Z." a écrit dans le message de
news:3fa7e68d$0$3658$
Hello,

oui c'est mon prenom alors tu peux m'appeler Thomas ;)

Qu'est ce qui te derange exactement avec le IN ? Je ne vois pas le


probleme
de maintenance ? ...

--
Salutations,
Thomas Zumbrunn


"Zim" wrote in message
news:
> Merci à tous ceux qui ont pris de leut temps pour me répondre (c'est
gentil,
> si, si !)
>
> Je vais tenter la solution XML : non pas qu'elle me semble la meilleure,
> mais c'est juste pour apprendre !!
>
> Par contre, Thomas (me permets-tu de t'appeler Thomas ?), tu me dis que


le
> besoin de paramètre optionels est souvent lié à un problème de design.
> Dans l'exemple que j'ai donné dans le premier post, comment t'y
prendrais-tu
> ?
>
> Rappel de l'exemple :
> Un table client, un table commande (contenant des montants), et je
> souhaiterai
> une somme de ces montants pour un certain nombre de commandes.
> (bien-sûr je ne veux pas passer par des requetes de type WHERE idFacture
IN
> (1, 56, 32, ...)
> où la maintenance est d'un pénible ....)
>
> Merci à tous,
>
> Zim.
>
> "Thomas Z." a écrit dans le message de
> news:3fa77883$0$3665$
> > Salut Zim,
> >
> > je vais m'y mettre aussi et proposer une solution un peux differente
meme
> si
> > je pense que le besoin de "param optionels" dans des stored (urk!;))


est
> > tres souvent lie a un probleme de design. Mais peut importe, voici une
> autre
> > solution qui s'integre a ta stored procedure, comme ca tu auras le
choix.
> >
> > Ici l'idee est du creer cote client un XML (.net a tous ce qu'il faut
pour
> > le faire) qui contient tes parametres, valeurs et de le passer ensuite


a
> ta
> > stored procedure dans un parametere texte de type varchar, dans la SP
> > generer un document XML le stocker dans une table temporaire que tu
> pourras
> > ensuite interroger comme une table normale (jointure etc...).
> >
> > Je t'ai fais un petit bout de code avec un bout d'XML d'exemple. Si la
> > solution t'interesse je pense que tu devrais assez facilement pouvoir


la
> > customiser pour tes besoins.
> >
> > <Code>
> >
> > DECLARE @ParamTable TABLE (
> > Name varchar (255),
> > Value int)
> >
> > DECLARE @XMLDoc int
> >
> > EXEC sp_xml_preparedocument @XMLDoc OUTPUT,
> > N'<ROOT>
> > <Parameters>
> > <Parameter Name="MonParam1" Value="1"/>
> > <Parameter Name="MonParam2" Value="2"/>
> > <Parameter Name="MonParam3" Value="3"/>
> > <Parameter Name="MonParam4" Value="4"/>
> > </Parameters>
> > </ROOT>'
> >
> > INSERT @ParamTable
> > SELECT *
> > FROM OPENXML(@XMLDoc, N'/ROOT/Parameters/Parameter')
> > WITH (Name varchar(255), Value int)
> >
> >
> > SELECT * FROM @ParamTable
> > EXEC sp_xml_removedocument @XMLDoc
> >
> > </code>
> >
> > Avec ca tu retrouveras dans la table @ParamTable tous tes parametres
(nom
> et
> > valeurs), il ne reste plus qu'a les utiliser :).
> >
> > --
> >
> > Salutations,
> > Thomas Zumbrunn
> >
> >
> > "Zim" wrote in message
> > news:%23KkoF$
> > > Bonjour à tous,
> > >
> > > ma question est la suivante : est-il possible dans SQL Server
> d'identifier
> > > une connexion de manière unique ?
> > > Je m'explique.
> > >
> > > Afin de simplifier mes procédures stockées qui nécessite un nombre
> > > indeterminés de paramètres
> > > (comprenez par là qu'il faudrait que je passe un tableau de
paramètres),
> > je
> > > me vois dans l'obligation de créer une
> > > table temporaire qui fait office de tableau.
> > >
> > > J'ai donc pensé (ça m'arrive), plutôt que de créer une table à


chaque
> > fois,
> > > j'en crée une définitive dans laquelle
> > > il y aura un champs qui me servira à détécter ma connexion. Pour


cela
> > > j'utilise la valeur @@SPID.
> > >
> > > En gros, le fonctionnement est le suivant: imaginons qu'un


utilisateur
> > > souhaite avoir le total de n factures,
> > > il se crée dans cette table les n identifiants de factures associées
au
> > > @@SPID du client en question (en espérant être clair).
> > > Ainsi, dans mes procédures stockées, il ne me reste qu'à faire une
> > jointure
> > > sur cette table avec comme paramètre le @@SPID :
> > >
> > > SELECT SUM(montant)
> > > FROM facture JOIN tableParam JOIN facture.id ON tableParam.idFacture
AND
> > > tableParam.spid = @@SPID
> > > (c'est simple et rapide).
> > >
> > > Par contre, mon problème est le suivant. Dans mon application web


(en
> > .NET),
> > > si un utilisateur attaquent la base alors qu'un autre utilisateur y
est
> > déjà
> > > présent,
> > > lors du rafraichissement des données, le premier utilisateur
"récupère"
> > les
> > > données de second, autrement dit, la connexion est la même !
> > > Effectivement, le @@SPID du second utilisateur devient celui de
premier.
> > >
> > > J'ai donc pensé forcer le pooling de la connexion à 'false' en
espérant
> > que
> > > la situation s'arrange, mais rien y fait.
> > > J'ai conscience de ne pas avoir été très clair, si quelqu'un pouvait
> tout
> > de
> > > même m'aider, je le remercie par avance.
> > >
> > > Zim.
> > >
> > >
> >
> >
>
>




Avatar
Thomas Z.
Hello,

dans une stored procedure tu peux faire de la maniere suivante pour simuler
un IN, recuperer un parametre de type varchar (@CSVParameters) en entree qui
receverai tes valeurs par exemple '1,2,3,4,5' puis tu peux faire de la facon
suivante sans devoir creer dynamquement un string :

SET @CSVParameters = ',' +@CSVParameters+ ','
SELECT * FROM MaTable WHERE @CSVParameters LIKE '%,' +IDFacture+ ',%'

Mais je crois que tu ne peux pas avoir de stored procedure ? .. Y a une
raison valable a ce choix ?

--
Salutations,
Thomas Zumbrunn


"Zim" wrote in message
news:
Bonsoir,

pour te répondre franchement, le soucis que j'ai avec les IN( x


paramètres )
est qu'il faut générer la requetes dynamiquement dans le code :
SQL = "SELECT * FROM table WHERE machin IN ("
foreach(string facture in collectionFacture)
SQL += facture +","
etc ...
D'autre part, je ne peux pas avoir de procédure stockées (qui accélère les
traitements).

D'où ma question : ai-je un problème de design de ma base ? et si oui,
comment y remédier.

Merci d'avoir pris le temps de me répondre.

Amicalement, Zim.

"Thomas Z." a écrit dans le message de
news:3fa7e68d$0$3658$
> Hello,
>
> oui c'est mon prenom alors tu peux m'appeler Thomas ;)
>
> Qu'est ce qui te derange exactement avec le IN ? Je ne vois pas le
probleme
> de maintenance ? ...
>
> --
> Salutations,
> Thomas Zumbrunn
>
>
> "Zim" wrote in message
> news:
> > Merci à tous ceux qui ont pris de leut temps pour me répondre (c'est
> gentil,
> > si, si !)
> >
> > Je vais tenter la solution XML : non pas qu'elle me semble la


meilleure,
> > mais c'est juste pour apprendre !!
> >
> > Par contre, Thomas (me permets-tu de t'appeler Thomas ?), tu me dis


que
le
> > besoin de paramètre optionels est souvent lié à un problème de design.
> > Dans l'exemple que j'ai donné dans le premier post, comment t'y
> prendrais-tu
> > ?
> >
> > Rappel de l'exemple :
> > Un table client, un table commande (contenant des montants), et je
> > souhaiterai
> > une somme de ces montants pour un certain nombre de commandes.
> > (bien-sûr je ne veux pas passer par des requetes de type WHERE


idFacture
> IN
> > (1, 56, 32, ...)
> > où la maintenance est d'un pénible ....)
> >
> > Merci à tous,
> >
> > Zim.
> >
> > "Thomas Z." a écrit dans le message de
> > news:3fa77883$0$3665$
> > > Salut Zim,
> > >
> > > je vais m'y mettre aussi et proposer une solution un peux differente
> meme
> > si
> > > je pense que le besoin de "param optionels" dans des stored (urk!;))
est
> > > tres souvent lie a un probleme de design. Mais peut importe, voici


une
> > autre
> > > solution qui s'integre a ta stored procedure, comme ca tu auras le
> choix.
> > >
> > > Ici l'idee est du creer cote client un XML (.net a tous ce qu'il


faut
> pour
> > > le faire) qui contient tes parametres, valeurs et de le passer


ensuite
a
> > ta
> > > stored procedure dans un parametere texte de type varchar, dans la


SP
> > > generer un document XML le stocker dans une table temporaire que tu
> > pourras
> > > ensuite interroger comme une table normale (jointure etc...).
> > >
> > > Je t'ai fais un petit bout de code avec un bout d'XML d'exemple. Si


la
> > > solution t'interesse je pense que tu devrais assez facilement


pouvoir
la
> > > customiser pour tes besoins.
> > >
> > > <Code>
> > >
> > > DECLARE @ParamTable TABLE (
> > > Name varchar (255),
> > > Value int)
> > >
> > > DECLARE @XMLDoc int
> > >
> > > EXEC sp_xml_preparedocument @XMLDoc OUTPUT,
> > > N'<ROOT>
> > > <Parameters>
> > > <Parameter Name="MonParam1" Value="1"/>
> > > <Parameter Name="MonParam2" Value="2"/>
> > > <Parameter Name="MonParam3" Value="3"/>
> > > <Parameter Name="MonParam4" Value="4"/>
> > > </Parameters>
> > > </ROOT>'
> > >
> > > INSERT @ParamTable
> > > SELECT *
> > > FROM OPENXML(@XMLDoc, N'/ROOT/Parameters/Parameter')
> > > WITH (Name varchar(255), Value int)
> > >
> > >
> > > SELECT * FROM @ParamTable
> > > EXEC sp_xml_removedocument @XMLDoc
> > >
> > > </code>
> > >
> > > Avec ca tu retrouveras dans la table @ParamTable tous tes parametres
> (nom
> > et
> > > valeurs), il ne reste plus qu'a les utiliser :).
> > >
> > > --
> > >
> > > Salutations,
> > > Thomas Zumbrunn
> > >
> > >
> > > "Zim" wrote in message
> > > news:%23KkoF$
> > > > Bonjour à tous,
> > > >
> > > > ma question est la suivante : est-il possible dans SQL Server
> > d'identifier
> > > > une connexion de manière unique ?
> > > > Je m'explique.
> > > >
> > > > Afin de simplifier mes procédures stockées qui nécessite un nombre
> > > > indeterminés de paramètres
> > > > (comprenez par là qu'il faudrait que je passe un tableau de
> paramètres),
> > > je
> > > > me vois dans l'obligation de créer une
> > > > table temporaire qui fait office de tableau.
> > > >
> > > > J'ai donc pensé (ça m'arrive), plutôt que de créer une table à
chaque
> > > fois,
> > > > j'en crée une définitive dans laquelle
> > > > il y aura un champs qui me servira à détécter ma connexion. Pour
cela
> > > > j'utilise la valeur @@SPID.
> > > >
> > > > En gros, le fonctionnement est le suivant: imaginons qu'un
utilisateur
> > > > souhaite avoir le total de n factures,
> > > > il se crée dans cette table les n identifiants de factures


associées
> au
> > > > @@SPID du client en question (en espérant être clair).
> > > > Ainsi, dans mes procédures stockées, il ne me reste qu'à faire une
> > > jointure
> > > > sur cette table avec comme paramètre le @@SPID :
> > > >
> > > > SELECT SUM(montant)
> > > > FROM facture JOIN tableParam JOIN facture.id ON


tableParam.idFacture
> AND
> > > > tableParam.spid = @@SPID
> > > > (c'est simple et rapide).
> > > >
> > > > Par contre, mon problème est le suivant. Dans mon application web
(en
> > > .NET),
> > > > si un utilisateur attaquent la base alors qu'un autre utilisateur


y
> est
> > > déjà
> > > > présent,
> > > > lors du rafraichissement des données, le premier utilisateur
> "récupère"
> > > les
> > > > données de second, autrement dit, la connexion est la même !
> > > > Effectivement, le @@SPID du second utilisateur devient celui de
> premier.
> > > >
> > > > J'ai donc pensé forcer le pooling de la connexion à 'false' en
> espérant
> > > que
> > > > la situation s'arrange, mais rien y fait.
> > > > J'ai conscience de ne pas avoir été très clair, si quelqu'un


pouvait
> > tout
> > > de
> > > > même m'aider, je le remercie par avance.
> > > >
> > > > Zim.
> > > >
> > > >
> > >
> > >
> >
> >
>
>




Avatar
Zim
Re,

Excuse-moi, mai je me suis mal exprimé quand je disais que je ne pouvais pas
avoir de procédure stockée ...
Bien au contraire, je n'utilise QUE des procédures stockées, et donc le fait
d'avoir une requête dynamique pour remplir mon 'IN' m'empéche d'en créer une
...

Amicalement,

Zim.


"Thomas Z." a écrit dans le message de
news:3fa80747$0$3663$
Hello,

dans une stored procedure tu peux faire de la maniere suivante pour


simuler
un IN, recuperer un parametre de type varchar (@CSVParameters) en entree


qui
receverai tes valeurs par exemple '1,2,3,4,5' puis tu peux faire de la


facon
suivante sans devoir creer dynamquement un string :

SET @CSVParameters = ',' +@CSVParameters+ ','
SELECT * FROM MaTable WHERE @CSVParameters LIKE '%,' +IDFacture+ ',%'

Mais je crois que tu ne peux pas avoir de stored procedure ? .. Y a une
raison valable a ce choix ?

--
Salutations,
Thomas Zumbrunn


"Zim" wrote in message
news:
> Bonsoir,
>
> pour te répondre franchement, le soucis que j'ai avec les IN( x
paramètres )
> est qu'il faut générer la requetes dynamiquement dans le code :
> SQL = "SELECT * FROM table WHERE machin IN ("
> foreach(string facture in collectionFacture)
> SQL += facture +","
> etc ...
> D'autre part, je ne peux pas avoir de procédure stockées (qui accélère


les
> traitements).
>
> D'où ma question : ai-je un problème de design de ma base ? et si oui,
> comment y remédier.
>
> Merci d'avoir pris le temps de me répondre.
>
> Amicalement, Zim.
>
> "Thomas Z." a écrit dans le message de
> news:3fa7e68d$0$3658$
> > Hello,
> >
> > oui c'est mon prenom alors tu peux m'appeler Thomas ;)
> >
> > Qu'est ce qui te derange exactement avec le IN ? Je ne vois pas le
> probleme
> > de maintenance ? ...
> >
> > --
> > Salutations,
> > Thomas Zumbrunn
> >
> >
> > "Zim" wrote in message
> > news:
> > > Merci à tous ceux qui ont pris de leut temps pour me répondre (c'est
> > gentil,
> > > si, si !)
> > >
> > > Je vais tenter la solution XML : non pas qu'elle me semble la
meilleure,
> > > mais c'est juste pour apprendre !!
> > >
> > > Par contre, Thomas (me permets-tu de t'appeler Thomas ?), tu me dis
que
> le
> > > besoin de paramètre optionels est souvent lié à un problème de


design.
> > > Dans l'exemple que j'ai donné dans le premier post, comment t'y
> > prendrais-tu
> > > ?
> > >
> > > Rappel de l'exemple :
> > > Un table client, un table commande (contenant des montants), et je
> > > souhaiterai
> > > une somme de ces montants pour un certain nombre de commandes.
> > > (bien-sûr je ne veux pas passer par des requetes de type WHERE
idFacture
> > IN
> > > (1, 56, 32, ...)
> > > où la maintenance est d'un pénible ....)
> > >
> > > Merci à tous,
> > >
> > > Zim.
> > >
> > > "Thomas Z." a écrit dans le message de
> > > news:3fa77883$0$3665$
> > > > Salut Zim,
> > > >
> > > > je vais m'y mettre aussi et proposer une solution un peux


differente
> > meme
> > > si
> > > > je pense que le besoin de "param optionels" dans des stored


(urk!;))
> est
> > > > tres souvent lie a un probleme de design. Mais peut importe, voici
une
> > > autre
> > > > solution qui s'integre a ta stored procedure, comme ca tu auras le
> > choix.
> > > >
> > > > Ici l'idee est du creer cote client un XML (.net a tous ce qu'il
faut
> > pour
> > > > le faire) qui contient tes parametres, valeurs et de le passer
ensuite
> a
> > > ta
> > > > stored procedure dans un parametere texte de type varchar, dans la
SP
> > > > generer un document XML le stocker dans une table temporaire que


tu
> > > pourras
> > > > ensuite interroger comme une table normale (jointure etc...).
> > > >
> > > > Je t'ai fais un petit bout de code avec un bout d'XML d'exemple.


Si
la
> > > > solution t'interesse je pense que tu devrais assez facilement
pouvoir
> la
> > > > customiser pour tes besoins.
> > > >
> > > > <Code>
> > > >
> > > > DECLARE @ParamTable TABLE (
> > > > Name varchar (255),
> > > > Value int)
> > > >
> > > > DECLARE @XMLDoc int
> > > >
> > > > EXEC sp_xml_preparedocument @XMLDoc OUTPUT,
> > > > N'<ROOT>
> > > > <Parameters>
> > > > <Parameter Name="MonParam1" Value="1"/>
> > > > <Parameter Name="MonParam2" Value="2"/>
> > > > <Parameter Name="MonParam3" Value="3"/>
> > > > <Parameter Name="MonParam4" Value="4"/>
> > > > </Parameters>
> > > > </ROOT>'
> > > >
> > > > INSERT @ParamTable
> > > > SELECT *
> > > > FROM OPENXML(@XMLDoc, N'/ROOT/Parameters/Parameter')
> > > > WITH (Name varchar(255), Value int)
> > > >
> > > >
> > > > SELECT * FROM @ParamTable
> > > > EXEC sp_xml_removedocument @XMLDoc
> > > >
> > > > </code>
> > > >
> > > > Avec ca tu retrouveras dans la table @ParamTable tous tes


parametres
> > (nom
> > > et
> > > > valeurs), il ne reste plus qu'a les utiliser :).
> > > >
> > > > --
> > > >
> > > > Salutations,
> > > > Thomas Zumbrunn
> > > >
> > > >
> > > > "Zim" wrote in message
> > > > news:%23KkoF$
> > > > > Bonjour à tous,
> > > > >
> > > > > ma question est la suivante : est-il possible dans SQL Server
> > > d'identifier
> > > > > une connexion de manière unique ?
> > > > > Je m'explique.
> > > > >
> > > > > Afin de simplifier mes procédures stockées qui nécessite un


nombre
> > > > > indeterminés de paramètres
> > > > > (comprenez par là qu'il faudrait que je passe un tableau de
> > paramètres),
> > > > je
> > > > > me vois dans l'obligation de créer une
> > > > > table temporaire qui fait office de tableau.
> > > > >
> > > > > J'ai donc pensé (ça m'arrive), plutôt que de créer une table à
> chaque
> > > > fois,
> > > > > j'en crée une définitive dans laquelle
> > > > > il y aura un champs qui me servira à détécter ma connexion. Pour
> cela
> > > > > j'utilise la valeur @@SPID.
> > > > >
> > > > > En gros, le fonctionnement est le suivant: imaginons qu'un
> utilisateur
> > > > > souhaite avoir le total de n factures,
> > > > > il se crée dans cette table les n identifiants de factures
associées
> > au
> > > > > @@SPID du client en question (en espérant être clair).
> > > > > Ainsi, dans mes procédures stockées, il ne me reste qu'à faire


une
> > > > jointure
> > > > > sur cette table avec comme paramètre le @@SPID :
> > > > >
> > > > > SELECT SUM(montant)
> > > > > FROM facture JOIN tableParam JOIN facture.id ON
tableParam.idFacture
> > AND
> > > > > tableParam.spid = @@SPID
> > > > > (c'est simple et rapide).
> > > > >
> > > > > Par contre, mon problème est le suivant. Dans mon application


web
> (en
> > > > .NET),
> > > > > si un utilisateur attaquent la base alors qu'un autre


utilisateur
y
> > est
> > > > déjà
> > > > > présent,
> > > > > lors du rafraichissement des données, le premier utilisateur
> > "récupère"
> > > > les
> > > > > données de second, autrement dit, la connexion est la même !
> > > > > Effectivement, le @@SPID du second utilisateur devient celui de
> > premier.
> > > > >
> > > > > J'ai donc pensé forcer le pooling de la connexion à 'false' en
> > espérant
> > > > que
> > > > > la situation s'arrange, mais rien y fait.
> > > > > J'ai conscience de ne pas avoir été très clair, si quelqu'un
pouvait
> > > tout
> > > > de
> > > > > même m'aider, je le remercie par avance.
> > > > >
> > > > > Zim.
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>




Avatar
Thomas Z.
Ca me rassure ;) Utilises l'astuce que je t'ai donne dans mon message
precedant et ca devrait resoudre tous tes problemes sans casse tete ;)

--
Salutations,
Thomas Zumbrunn


"Zim" wrote in message
news:
Re,

Excuse-moi, mai je me suis mal exprimé quand je disais que je ne pouvais


pas
avoir de procédure stockée ...
Bien au contraire, je n'utilise QUE des procédures stockées, et donc le


fait
d'avoir une requête dynamique pour remplir mon 'IN' m'empéche d'en créer


une
...

Amicalement,

Zim.


"Thomas Z." a écrit dans le message de
news:3fa80747$0$3663$
> Hello,
>
> dans une stored procedure tu peux faire de la maniere suivante pour
simuler
> un IN, recuperer un parametre de type varchar (@CSVParameters) en entree
qui
> receverai tes valeurs par exemple '1,2,3,4,5' puis tu peux faire de la
facon
> suivante sans devoir creer dynamquement un string :
>
> SET @CSVParameters = ',' +@CSVParameters+ ','
> SELECT * FROM MaTable WHERE @CSVParameters LIKE '%,' +IDFacture+ ',%'
>
> Mais je crois que tu ne peux pas avoir de stored procedure ? .. Y a une
> raison valable a ce choix ?
>
> --
> Salutations,
> Thomas Zumbrunn
>
>
> "Zim" wrote in message
> news:
> > Bonsoir,
> >
> > pour te répondre franchement, le soucis que j'ai avec les IN( x
> paramètres )
> > est qu'il faut générer la requetes dynamiquement dans le code :
> > SQL = "SELECT * FROM table WHERE machin IN ("
> > foreach(string facture in collectionFacture)
> > SQL += facture +","
> > etc ...
> > D'autre part, je ne peux pas avoir de procédure stockées (qui accélère
les
> > traitements).
> >
> > D'où ma question : ai-je un problème de design de ma base ? et si oui,
> > comment y remédier.
> >
> > Merci d'avoir pris le temps de me répondre.
> >
> > Amicalement, Zim.
> >
> > "Thomas Z." a écrit dans le message de
> > news:3fa7e68d$0$3658$
> > > Hello,
> > >
> > > oui c'est mon prenom alors tu peux m'appeler Thomas ;)
> > >
> > > Qu'est ce qui te derange exactement avec le IN ? Je ne vois pas le
> > probleme
> > > de maintenance ? ...
> > >
> > > --
> > > Salutations,
> > > Thomas Zumbrunn
> > >
> > >
> > > "Zim" wrote in message
> > > news:
> > > > Merci à tous ceux qui ont pris de leut temps pour me répondre


(c'est
> > > gentil,
> > > > si, si !)
> > > >
> > > > Je vais tenter la solution XML : non pas qu'elle me semble la
> meilleure,
> > > > mais c'est juste pour apprendre !!
> > > >
> > > > Par contre, Thomas (me permets-tu de t'appeler Thomas ?), tu me


dis
> que
> > le
> > > > besoin de paramètre optionels est souvent lié à un problème de
design.
> > > > Dans l'exemple que j'ai donné dans le premier post, comment t'y
> > > prendrais-tu
> > > > ?
> > > >
> > > > Rappel de l'exemple :
> > > > Un table client, un table commande (contenant des montants), et je
> > > > souhaiterai
> > > > une somme de ces montants pour un certain nombre de commandes.
> > > > (bien-sûr je ne veux pas passer par des requetes de type WHERE
> idFacture
> > > IN
> > > > (1, 56, 32, ...)
> > > > où la maintenance est d'un pénible ....)
> > > >
> > > > Merci à tous,
> > > >
> > > > Zim.
> > > >
> > > > "Thomas Z." a écrit dans le message


de
> > > > news:3fa77883$0$3665$
> > > > > Salut Zim,
> > > > >
> > > > > je vais m'y mettre aussi et proposer une solution un peux
differente
> > > meme
> > > > si
> > > > > je pense que le besoin de "param optionels" dans des stored
(urk!;))
> > est
> > > > > tres souvent lie a un probleme de design. Mais peut importe,


voici
> une
> > > > autre
> > > > > solution qui s'integre a ta stored procedure, comme ca tu auras


le
> > > choix.
> > > > >
> > > > > Ici l'idee est du creer cote client un XML (.net a tous ce qu'il
> faut
> > > pour
> > > > > le faire) qui contient tes parametres, valeurs et de le passer
> ensuite
> > a
> > > > ta
> > > > > stored procedure dans un parametere texte de type varchar, dans


la
> SP
> > > > > generer un document XML le stocker dans une table temporaire que
tu
> > > > pourras
> > > > > ensuite interroger comme une table normale (jointure etc...).
> > > > >
> > > > > Je t'ai fais un petit bout de code avec un bout d'XML d'exemple.
Si
> la
> > > > > solution t'interesse je pense que tu devrais assez facilement
> pouvoir
> > la
> > > > > customiser pour tes besoins.
> > > > >
> > > > > <Code>
> > > > >
> > > > > DECLARE @ParamTable TABLE (
> > > > > Name varchar (255),
> > > > > Value int)
> > > > >
> > > > > DECLARE @XMLDoc int
> > > > >
> > > > > EXEC sp_xml_preparedocument @XMLDoc OUTPUT,
> > > > > N'<ROOT>
> > > > > <Parameters>
> > > > > <Parameter Name="MonParam1" Value="1"/>
> > > > > <Parameter Name="MonParam2" Value="2"/>
> > > > > <Parameter Name="MonParam3" Value="3"/>
> > > > > <Parameter Name="MonParam4" Value="4"/>
> > > > > </Parameters>
> > > > > </ROOT>'
> > > > >
> > > > > INSERT @ParamTable
> > > > > SELECT *
> > > > > FROM OPENXML(@XMLDoc, N'/ROOT/Parameters/Parameter')
> > > > > WITH (Name varchar(255), Value int)
> > > > >
> > > > >
> > > > > SELECT * FROM @ParamTable
> > > > > EXEC sp_xml_removedocument @XMLDoc
> > > > >
> > > > > </code>
> > > > >
> > > > > Avec ca tu retrouveras dans la table @ParamTable tous tes
parametres
> > > (nom
> > > > et
> > > > > valeurs), il ne reste plus qu'a les utiliser :).
> > > > >
> > > > > --
> > > > >
> > > > > Salutations,
> > > > > Thomas Zumbrunn
> > > > >
> > > > >
> > > > > "Zim" wrote in message
> > > > > news:%23KkoF$
> > > > > > Bonjour à tous,
> > > > > >
> > > > > > ma question est la suivante : est-il possible dans SQL Server
> > > > d'identifier
> > > > > > une connexion de manière unique ?
> > > > > > Je m'explique.
> > > > > >
> > > > > > Afin de simplifier mes procédures stockées qui nécessite un
nombre
> > > > > > indeterminés de paramètres
> > > > > > (comprenez par là qu'il faudrait que je passe un tableau de
> > > paramètres),
> > > > > je
> > > > > > me vois dans l'obligation de créer une
> > > > > > table temporaire qui fait office de tableau.
> > > > > >
> > > > > > J'ai donc pensé (ça m'arrive), plutôt que de créer une table à
> > chaque
> > > > > fois,
> > > > > > j'en crée une définitive dans laquelle
> > > > > > il y aura un champs qui me servira à détécter ma connexion.


Pour
> > cela
> > > > > > j'utilise la valeur @@SPID.
> > > > > >
> > > > > > En gros, le fonctionnement est le suivant: imaginons qu'un
> > utilisateur
> > > > > > souhaite avoir le total de n factures,
> > > > > > il se crée dans cette table les n identifiants de factures
> associées
> > > au
> > > > > > @@SPID du client en question (en espérant être clair).
> > > > > > Ainsi, dans mes procédures stockées, il ne me reste qu'à faire
une
> > > > > jointure
> > > > > > sur cette table avec comme paramètre le @@SPID :
> > > > > >
> > > > > > SELECT SUM(montant)
> > > > > > FROM facture JOIN tableParam JOIN facture.id ON
> tableParam.idFacture
> > > AND
> > > > > > tableParam.spid = @@SPID
> > > > > > (c'est simple et rapide).
> > > > > >
> > > > > > Par contre, mon problème est le suivant. Dans mon application
web
> > (en
> > > > > .NET),
> > > > > > si un utilisateur attaquent la base alors qu'un autre
utilisateur
> y
> > > est
> > > > > déjà
> > > > > > présent,
> > > > > > lors du rafraichissement des données, le premier utilisateur
> > > "récupère"
> > > > > les
> > > > > > données de second, autrement dit, la connexion est la même !
> > > > > > Effectivement, le @@SPID du second utilisateur devient celui


de
> > > premier.
> > > > > >
> > > > > > J'ai donc pensé forcer le pooling de la connexion à 'false' en
> > > espérant
> > > > > que
> > > > > > la situation s'arrange, mais rien y fait.
> > > > > > J'ai conscience de ne pas avoir été très clair, si quelqu'un
> pouvait
> > > > tout
> > > > > de
> > > > > > même m'aider, je le remercie par avance.
> > > > > >
> > > > > > Zim.
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>




Avatar
Pierre Goiffon
Dans le message:,
Nicolas LETULLIER a écrit:
En additif aux idées de Nicolas et Patrice, l'adresse IP du client
est aussi un moyen rapide de l'identifier de manière unique





Ca peut en effet l'être parfois, mais peut également poser des
problèmes. En effet, tous les clients SQL Server seront le serveur
web, donc la même adresse IP. Si tu parlais de l'adresse IP des
clients Web finaux, il y a là aussi un risque sur un grand nombre de
connexions simultanées car par exemple, chez AOL (toujours eux),
toutes les requêtes HTTP passent par un proxy, donc juste quelques
adresses différentes.



Et il y a aussi tous les routeurs NAT, ce qui au final finit par
concerner beaucoup de monde !

--
..::: Pierre GOIFFON :::..

Un grand merci à OE Quote Fix pour rendre OE utilisable :)
=> http://home.in.tum.de/~jain/software/quotefix.php

(email temporairement supprimé pour cause de déferlante Swen :( )
Avatar
fred
Bonsoir,
et pourquoi ne pas mettre ton appli .net en gestion d'état Sql Server....
puis tu regardes la fçon dont il gère...
c'est intéressant et instructif.
@+
fred
"Pierre Goiffon" a écrit dans le message de news:
3fa903cf$0$2801$
Dans le message:,
Nicolas LETULLIER a écrit:
>> En additif aux idées de Nicolas et Patrice, l'adresse IP du client
>> est aussi un moyen rapide de l'identifier de manière unique

> Ca peut en effet l'être parfois, mais peut également poser des
> problèmes. En effet, tous les clients SQL Server seront le serveur
> web, donc la même adresse IP. Si tu parlais de l'adresse IP des
> clients Web finaux, il y a là aussi un risque sur un grand nombre de
> connexions simultanées car par exemple, chez AOL (toujours eux),
> toutes les requêtes HTTP passent par un proxy, donc juste quelques
> adresses différentes.

Et il y a aussi tous les routeurs NAT, ce qui au final finit par
concerner beaucoup de monde !

--
..::: Pierre GOIFFON :::..

Un grand merci à OE Quote Fix pour rendre OE utilisable :)
=> http://home.in.tum.de/~jain/software/quotefix.php

(email temporairement supprimé pour cause de déferlante Swen :( )



1 2