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

10 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
Nicolas LETULLIER
Bonjour,

J'ai bien peur que le pooling de connexions te pose un gros problème en
effet.
Petite idée, ne pourrais-tu pas utiliser une autre table ayant un champ
IDENTITY qui en début de ton traitement (avant l'insertion de tes paramètres
dans ta table temporaire), te crée un numéro unique que tu passerais ensuite
comme paramètre de tes autres procédures stockées ? En fin de traitement, tu
ferais alors un DELETE dans ta table de compteur. Le champ IDENTITY est une
possibilité, un RAND en aurait été une autre, peut-être plus facile, mais
moins sûre.

C'est un peu de la bidouille (j'en entends déjà certains crier à l'hérésie),
mais cela te permettrait de t'en sortir sans trop de redéveloppements, non ?

Nicolas.


"Zim" a écrit dans le message de
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
Bonjour Nicolas (enfin bonsoir),

Merci de m'avoir répondu. Apparement, j'ai quand même réussi à poser mon
problème assez clairement.
Effectivement, la piste que tu me donnes est une très bonne idée, je vais
essayer de mettre en place cette solution si toutefois je n'arrive pas à
résoudre ce pb de pool (si c'est bien de cela qu'il s'agit ...)

Je n'arrive pas à comprendre qu'on ne puisse pas simplement "réserver" une
connexion à une session (je suppose que c'est ADO.NET qui est cause et non
pas SQL server).
Il doit y a voir un paramètre quelconque quelquepart ... mais où ?

En tout cas merci pour ta piste !

Zim.


"Nicolas LETULLIER" a écrit dans le
message de news:
Bonjour,

J'ai bien peur que le pooling de connexions te pose un gros problème en
effet.
Petite idée, ne pourrais-tu pas utiliser une autre table ayant un champ
IDENTITY qui en début de ton traitement (avant l'insertion de tes


paramètres
dans ta table temporaire), te crée un numéro unique que tu passerais


ensuite
comme paramètre de tes autres procédures stockées ? En fin de traitement,


tu
ferais alors un DELETE dans ta table de compteur. Le champ IDENTITY est


une
possibilité, un RAND en aurait été une autre, peut-être plus facile, mais
moins sûre.

C'est un peu de la bidouille (j'en entends déjà certains crier à


l'hérésie),
mais cela te permettrait de t'en sortir sans trop de redéveloppements, non


?

Nicolas.


"Zim" a écrit dans le message de
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
Patrice Scribe
En désactivant le pool ! mais ce n'est probalement pas conseillé.

Le fond du problème est que le numéro doit-être unique dans le temps :
- un GUID par exemple devrait faire l'affaire.

Côté .NET tu peux voir aussi du côté du numéro de session qui est maintenant
une chaîne complexe (je pense que la modification a justement été faire pour
pouvoir persister les variables de session en base sans justement ce souci
de recyclage. A vérifier tout de même avant application).

Ce n'est pas la connexion SQL Server q'il faut identifier, c'est plutôt la
session ASP.NET (dont le numéro donc est probablement maintenant non
recyclable)...

Patrice

--

"Zim" a écrit dans le message de
news:
Bonjour Nicolas (enfin bonsoir),

Merci de m'avoir répondu. Apparement, j'ai quand même réussi à poser mon
problème assez clairement.
Effectivement, la piste que tu me donnes est une très bonne idée, je vais
essayer de mettre en place cette solution si toutefois je n'arrive pas à
résoudre ce pb de pool (si c'est bien de cela qu'il s'agit ...)

Je n'arrive pas à comprendre qu'on ne puisse pas simplement "réserver" une
connexion à une session (je suppose que c'est ADO.NET qui est cause et non
pas SQL server).
Il doit y a voir un paramètre quelconque quelquepart ... mais où ?

En tout cas merci pour ta piste !

Zim.


"Nicolas LETULLIER" a écrit dans le
message de news:
> Bonjour,
>
> J'ai bien peur que le pooling de connexions te pose un gros problème en
> effet.
> Petite idée, ne pourrais-tu pas utiliser une autre table ayant un champ
> IDENTITY qui en début de ton traitement (avant l'insertion de tes
paramètres
> dans ta table temporaire), te crée un numéro unique que tu passerais
ensuite
> comme paramètre de tes autres procédures stockées ? En fin de


traitement,
tu
> ferais alors un DELETE dans ta table de compteur. Le champ IDENTITY est
une
> possibilité, un RAND en aurait été une autre, peut-être plus facile,


mais
> moins sûre.
>
> C'est un peu de la bidouille (j'en entends déjà certains crier à
l'hérésie),
> mais cela te permettrait de t'en sortir sans trop de redéveloppements,


non
?
>
> Nicolas.
>
>
> "Zim" a écrit dans le message de
> 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
Med Bouchenafa [MVP]
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

--
Salutations
Med Bouchenafa
TETRASET
75015 Paris
"Patrice Scribe" a écrit dans le message de news:

En désactivant le pool ! mais ce n'est probalement pas conseillé.

Le fond du problème est que le numéro doit-être unique dans le temps :
- un GUID par exemple devrait faire l'affaire.

Côté .NET tu peux voir aussi du côté du numéro de session qui est maintenant
une chaîne complexe (je pense que la modification a justement été faire pour
pouvoir persister les variables de session en base sans justement ce souci
de recyclage. A vérifier tout de même avant application).

Ce n'est pas la connexion SQL Server q'il faut identifier, c'est plutôt la
session ASP.NET (dont le numéro donc est probablement maintenant non
recyclable)...

Patrice

--

"Zim" a écrit dans le message de
news:
> Bonjour Nicolas (enfin bonsoir),
>
> Merci de m'avoir répondu. Apparement, j'ai quand même réussi à poser mon
> problème assez clairement.
> Effectivement, la piste que tu me donnes est une très bonne idée, je vais
> essayer de mettre en place cette solution si toutefois je n'arrive pas à
> résoudre ce pb de pool (si c'est bien de cela qu'il s'agit ...)
>
> Je n'arrive pas à comprendre qu'on ne puisse pas simplement "réserver" une
> connexion à une session (je suppose que c'est ADO.NET qui est cause et non
> pas SQL server).
> Il doit y a voir un paramètre quelconque quelquepart ... mais où ?
>
> En tout cas merci pour ta piste !
>
> Zim.
>
>
> "Nicolas LETULLIER" a écrit dans le
> message de news:
> > Bonjour,
> >
> > J'ai bien peur que le pooling de connexions te pose un gros problème en
> > effet.
> > Petite idée, ne pourrais-tu pas utiliser une autre table ayant un champ
> > IDENTITY qui en début de ton traitement (avant l'insertion de tes
> paramètres
> > dans ta table temporaire), te crée un numéro unique que tu passerais
> ensuite
> > comme paramètre de tes autres procédures stockées ? En fin de
traitement,
> tu
> > ferais alors un DELETE dans ta table de compteur. Le champ IDENTITY est
> une
> > possibilité, un RAND en aurait été une autre, peut-être plus facile,
mais
> > moins sûre.
> >
> > C'est un peu de la bidouille (j'en entends déjà certains crier à
> l'hérésie),
> > mais cela te permettrait de t'en sortir sans trop de redéveloppements,
non
> ?
> >
> > Nicolas.
> >
> >
> > "Zim" a écrit dans le message de
> > 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
Merci à tous pour votre aide.

J'aimerai toutefois savoir comment on désactive le pool. Le fait d'ajouter
pooligúlse à la chaine de connexion ne résoud pas mon problème.
Y aurait-il un autre paramètre ?

Je tiens à préciser que mon appli web est un extranet où très peu de clients
vont se connecter, donc la désactivation de pool ne va pas beaucoup faire
chuter les performances ...

Merci encore,

Zim.

"Med Bouchenafa [MVP]" a écrit dans le message de
news:%
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

--
Salutations
Med Bouchenafa
TETRASET
75015 Paris
"Patrice Scribe" a écrit dans le message de news:

> En désactivant le pool ! mais ce n'est probalement pas conseillé.
>
> Le fond du problème est que le numéro doit-être unique dans le temps :
> - un GUID par exemple devrait faire l'affaire.
>
> Côté .NET tu peux voir aussi du côté du numéro de session qui est


maintenant
> une chaîne complexe (je pense que la modification a justement été faire


pour
> pouvoir persister les variables de session en base sans justement ce


souci
> de recyclage. A vérifier tout de même avant application).
>
> Ce n'est pas la connexion SQL Server q'il faut identifier, c'est plutôt


la
> session ASP.NET (dont le numéro donc est probablement maintenant non
> recyclable)...
>
> Patrice
>
> --
>
> "Zim" a écrit dans le message de
> news:
> > Bonjour Nicolas (enfin bonsoir),
> >
> > Merci de m'avoir répondu. Apparement, j'ai quand même réussi à poser


mon
> > problème assez clairement.
> > Effectivement, la piste que tu me donnes est une très bonne idée, je


vais
> > essayer de mettre en place cette solution si toutefois je n'arrive pas


à
> > résoudre ce pb de pool (si c'est bien de cela qu'il s'agit ...)
> >
> > Je n'arrive pas à comprendre qu'on ne puisse pas simplement "réserver"


une
> > connexion à une session (je suppose que c'est ADO.NET qui est cause et


non
> > pas SQL server).
> > Il doit y a voir un paramètre quelconque quelquepart ... mais où ?
> >
> > En tout cas merci pour ta piste !
> >
> > Zim.
> >
> >
> > "Nicolas LETULLIER" a écrit dans


le
> > message de news:
> > > Bonjour,
> > >
> > > J'ai bien peur que le pooling de connexions te pose un gros problème


en
> > > effet.
> > > Petite idée, ne pourrais-tu pas utiliser une autre table ayant un


champ
> > > IDENTITY qui en début de ton traitement (avant l'insertion de tes
> > paramètres
> > > dans ta table temporaire), te crée un numéro unique que tu passerais
> > ensuite
> > > comme paramètre de tes autres procédures stockées ? En fin de
> traitement,
> > tu
> > > ferais alors un DELETE dans ta table de compteur. Le champ IDENTITY


est
> > une
> > > possibilité, un RAND en aurait été une autre, peut-être plus facile,
> mais
> > > moins sûre.
> > >
> > > C'est un peu de la bidouille (j'en entends déjà certains crier à
> > l'hérésie),
> > > mais cela te permettrait de t'en sortir sans trop de


redéveloppements,
> non
> > ?
> > >
> > > Nicolas.
> > >
> > >
> > > "Zim" a écrit dans le


message de
> > > 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
Nicolas LETULLIER
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.

Nicolas.


"Med Bouchenafa [MVP]" a écrit dans le message de
news:%
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

--
Salutations
Med Bouchenafa
TETRASET
75015 Paris


Avatar
Patrice Scribe
D'après la doc. cela devrait suffire (pour SqlClient, peut-être OleDB
Services si tu es en OleDb). Un groupe .NET serait sans doute de plus de
secours...

Cette approche me parait tout de même à déconseiller. Même sans pooling, que
se passe t'il si une connection utilise le même SPID qu'une connexion
précédente qui est terminée ? Si par exemple tu as un mécanisme de
"presse-papier" (pk enregistrés dans une table), l'utilisateur de la
deuxième connection pourrait "coller" les données mis dans ce presse papier
par l'utilisateur précédent.

Conceptuellement, il me semble que tu veux identifier la session utilisateur
et le SessionID me semble un bon candidat :

Each active ASP.NET session is identified and tracked




using a 120-bit SessionID string containing only the ASCII characters that
are allowed in URLs. SessionID values are generated using an algorithm that
guarantees uniqueness so that sessions do not collide, and randomness so
that a malicious user cannot use a new SessionID to calculate the SessionID
of an existing session.

Il semble effectivement être unique (même si je fais le forcing pour que
l'on me confirme qu'il est calculé à partir d'un GUID)....

(un groupe .NET peut-être plus adapté pour la suite)

Patrice

--

"Zim" a écrit dans le message de
news:%
Merci à tous pour votre aide.

J'aimerai toutefois savoir comment on désactive le pool. Le fait d'ajouter
pooligúlse à la chaine de connexion ne résoud pas mon problème.
Y aurait-il un autre paramètre ?

Je tiens à préciser que mon appli web est un extranet où très peu de


clients
vont se connecter, donc la désactivation de pool ne va pas beaucoup faire
chuter les performances ...

Merci encore,

Zim.

"Med Bouchenafa [MVP]" a écrit dans le message


de
news:%
> 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
>
> --
> Salutations
> Med Bouchenafa
> TETRASET
> 75015 Paris
> "Patrice Scribe" a écrit dans le message de news:
>
> > En désactivant le pool ! mais ce n'est probalement pas conseillé.
> >
> > Le fond du problème est que le numéro doit-être unique dans le temps :
> > - un GUID par exemple devrait faire l'affaire.
> >
> > Côté .NET tu peux voir aussi du côté du numéro de session qui est
maintenant
> > une chaîne complexe (je pense que la modification a justement été


faire
pour
> > pouvoir persister les variables de session en base sans justement ce
souci
> > de recyclage. A vérifier tout de même avant application).
> >
> > Ce n'est pas la connexion SQL Server q'il faut identifier, c'est


plutôt
la
> > session ASP.NET (dont le numéro donc est probablement maintenant non
> > recyclable)...
> >
> > Patrice
> >
> > --
> >
> > "Zim" a écrit dans le message


de
> > news:
> > > Bonjour Nicolas (enfin bonsoir),
> > >
> > > Merci de m'avoir répondu. Apparement, j'ai quand même réussi à


poser
mon
> > > problème assez clairement.
> > > Effectivement, la piste que tu me donnes est une très bonne idée, je
vais
> > > essayer de mettre en place cette solution si toutefois je n'arrive


pas
à
> > > résoudre ce pb de pool (si c'est bien de cela qu'il s'agit ...)
> > >
> > > Je n'arrive pas à comprendre qu'on ne puisse pas simplement


"réserver"
une
> > > connexion à une session (je suppose que c'est ADO.NET qui est cause


et
non
> > > pas SQL server).
> > > Il doit y a voir un paramètre quelconque quelquepart ... mais où ?
> > >
> > > En tout cas merci pour ta piste !
> > >
> > > Zim.
> > >
> > >
> > > "Nicolas LETULLIER" a écrit dans
le
> > > message de news:
> > > > Bonjour,
> > > >
> > > > J'ai bien peur que le pooling de connexions te pose un gros


problème
en
> > > > effet.
> > > > Petite idée, ne pourrais-tu pas utiliser une autre table ayant un
champ
> > > > IDENTITY qui en début de ton traitement (avant l'insertion de tes
> > > paramètres
> > > > dans ta table temporaire), te crée un numéro unique que tu


passerais
> > > ensuite
> > > > comme paramètre de tes autres procédures stockées ? En fin de
> > traitement,
> > > tu
> > > > ferais alors un DELETE dans ta table de compteur. Le champ


IDENTITY
est
> > > une
> > > > possibilité, un RAND en aurait été une autre, peut-être plus


facile,
> > mais
> > > > moins sûre.
> > > >
> > > > C'est un peu de la bidouille (j'en entends déjà certains crier à
> > > l'hérésie),
> > > > mais cela te permettrait de t'en sortir sans trop de
redéveloppements,
> > non
> > > ?
> > > >
> > > > Nicolas.
> > > >
> > > >
> > > > "Zim" a écrit dans le
message de
> > > > 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.
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
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,

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




1 2