Bonjour,
J'ai un petit souci. Une application en .NET accède à une base de données
SQLServer 2000 via ADO, en n'utilisant les ressources qu'en cas de besoin.
Suite à une login form, je charge depuis le SGBD un profil et quelques infos
que je stocke dans une classe "session". Ensuite, j'arrive dans une form type
"modules autorisés", chaque module cliqué ouvrant une nouvelle form qui, en
fonction de critères, ouvre une connexion, charge des données via une
procédure stockée, puis referme la connexion et laisse le garbage collector
libérer les ressources allouées. Tant que l'utilisateur n'agit pas, pas de
connexion au serveur SQL.
Or, je me retrouve pendant la durée de vie de l'application avec des
connexions SQL dans le volet Activités d'Enterprise Manager (2, en général
par client de cette application) et des verrous DB. Tout ce petit bestiaire
s'évanouit dès qu'on termine l'application...
a) Comme mes connexions sont encapsulées dans des Try...Finally, il est
théoriquement impossible de laisser une connexion active. Comment cela se
peut-il donc ?
b) Que sont au juste ces verrous DB qui apparaissent ?
Merci de m'aider, si vous le pouvez.
Jean-Yves
P.S: une connexion ouverte via Canaux nommés est-elle plus facilement
"killable" qu'une autre ouverte à travers Socket TCP/IP ? J'ai le cas de
figure et je ne comprends pas pourquoi une connexion Enterprise Manager se
tue très bien avec son spid, alors qu'une connexion via ADO/Socket résiste à
tout kill...
(re)merci.
Bonjour,
J'ai un petit souci. Une application en .NET accède à une base de données
SQLServer 2000 via ADO, en n'utilisant les ressources qu'en cas de besoin.
Suite à une login form, je charge depuis le SGBD un profil et quelques infos
que je stocke dans une classe "session". Ensuite, j'arrive dans une form type
"modules autorisés", chaque module cliqué ouvrant une nouvelle form qui, en
fonction de critères, ouvre une connexion, charge des données via une
procédure stockée, puis referme la connexion et laisse le garbage collector
libérer les ressources allouées. Tant que l'utilisateur n'agit pas, pas de
connexion au serveur SQL.
Or, je me retrouve pendant la durée de vie de l'application avec des
connexions SQL dans le volet Activités d'Enterprise Manager (2, en général
par client de cette application) et des verrous DB. Tout ce petit bestiaire
s'évanouit dès qu'on termine l'application...
a) Comme mes connexions sont encapsulées dans des Try...Finally, il est
théoriquement impossible de laisser une connexion active. Comment cela se
peut-il donc ?
b) Que sont au juste ces verrous DB qui apparaissent ?
Merci de m'aider, si vous le pouvez.
Jean-Yves
P.S: une connexion ouverte via Canaux nommés est-elle plus facilement
"killable" qu'une autre ouverte à travers Socket TCP/IP ? J'ai le cas de
figure et je ne comprends pas pourquoi une connexion Enterprise Manager se
tue très bien avec son spid, alors qu'une connexion via ADO/Socket résiste à
tout kill...
(re)merci.
Bonjour,
J'ai un petit souci. Une application en .NET accède à une base de données
SQLServer 2000 via ADO, en n'utilisant les ressources qu'en cas de besoin.
Suite à une login form, je charge depuis le SGBD un profil et quelques infos
que je stocke dans une classe "session". Ensuite, j'arrive dans une form type
"modules autorisés", chaque module cliqué ouvrant une nouvelle form qui, en
fonction de critères, ouvre une connexion, charge des données via une
procédure stockée, puis referme la connexion et laisse le garbage collector
libérer les ressources allouées. Tant que l'utilisateur n'agit pas, pas de
connexion au serveur SQL.
Or, je me retrouve pendant la durée de vie de l'application avec des
connexions SQL dans le volet Activités d'Enterprise Manager (2, en général
par client de cette application) et des verrous DB. Tout ce petit bestiaire
s'évanouit dès qu'on termine l'application...
a) Comme mes connexions sont encapsulées dans des Try...Finally, il est
théoriquement impossible de laisser une connexion active. Comment cela se
peut-il donc ?
b) Que sont au juste ces verrous DB qui apparaissent ?
Merci de m'aider, si vous le pouvez.
Jean-Yves
P.S: une connexion ouverte via Canaux nommés est-elle plus facilement
"killable" qu'une autre ouverte à travers Socket TCP/IP ? J'ai le cas de
figure et je ne comprends pas pourquoi une connexion Enterprise Manager se
tue très bien avec son spid, alors qu'une connexion via ADO/Socket résiste à
tout kill...
(re)merci.
Bonjour,
Cela indique simplement qu'un utilisateur connecté est dans la base dont
l'identifiant est dans la colonne dbid (hors master).
Cordialement,
LionelP
"Jean-Yves" wrote:
> Bonjour,
>
> J'ai un petit souci. Une application en .NET accède à une base de données
> SQLServer 2000 via ADO, en n'utilisant les ressources qu'en cas de besoin.
> Suite à une login form, je charge depuis le SGBD un profil et quelques infos
> que je stocke dans une classe "session". Ensuite, j'arrive dans une form type
> "modules autorisés", chaque module cliqué ouvrant une nouvelle form qui, en
> fonction de critères, ouvre une connexion, charge des données via une
> procédure stockée, puis referme la connexion et laisse le garbage collector
> libérer les ressources allouées. Tant que l'utilisateur n'agit pas, pas de
> connexion au serveur SQL.
> Or, je me retrouve pendant la durée de vie de l'application avec des
> connexions SQL dans le volet Activités d'Enterprise Manager (2, en général
> par client de cette application) et des verrous DB. Tout ce petit bestiaire
> s'évanouit dès qu'on termine l'application...
>
> a) Comme mes connexions sont encapsulées dans des Try...Finally, il est
> théoriquement impossible de laisser une connexion active. Comment cela se
> peut-il donc ?
> b) Que sont au juste ces verrous DB qui apparaissent ?
>
> Merci de m'aider, si vous le pouvez.
> Jean-Yves
>
> P.S: une connexion ouverte via Canaux nommés est-elle plus facilement
> "killable" qu'une autre ouverte à travers Socket TCP/IP ? J'ai le cas de
> figure et je ne comprends pas pourquoi une connexion Enterprise Manager se
> tue très bien avec son spid, alors qu'une connexion via ADO/Socket résiste à
> tout kill...
> (re)merci.
Bonjour,
Cela indique simplement qu'un utilisateur connecté est dans la base dont
l'identifiant est dans la colonne dbid (hors master).
Cordialement,
LionelP
"Jean-Yves" wrote:
> Bonjour,
>
> J'ai un petit souci. Une application en .NET accède à une base de données
> SQLServer 2000 via ADO, en n'utilisant les ressources qu'en cas de besoin.
> Suite à une login form, je charge depuis le SGBD un profil et quelques infos
> que je stocke dans une classe "session". Ensuite, j'arrive dans une form type
> "modules autorisés", chaque module cliqué ouvrant une nouvelle form qui, en
> fonction de critères, ouvre une connexion, charge des données via une
> procédure stockée, puis referme la connexion et laisse le garbage collector
> libérer les ressources allouées. Tant que l'utilisateur n'agit pas, pas de
> connexion au serveur SQL.
> Or, je me retrouve pendant la durée de vie de l'application avec des
> connexions SQL dans le volet Activités d'Enterprise Manager (2, en général
> par client de cette application) et des verrous DB. Tout ce petit bestiaire
> s'évanouit dès qu'on termine l'application...
>
> a) Comme mes connexions sont encapsulées dans des Try...Finally, il est
> théoriquement impossible de laisser une connexion active. Comment cela se
> peut-il donc ?
> b) Que sont au juste ces verrous DB qui apparaissent ?
>
> Merci de m'aider, si vous le pouvez.
> Jean-Yves
>
> P.S: une connexion ouverte via Canaux nommés est-elle plus facilement
> "killable" qu'une autre ouverte à travers Socket TCP/IP ? J'ai le cas de
> figure et je ne comprends pas pourquoi une connexion Enterprise Manager se
> tue très bien avec son spid, alors qu'une connexion via ADO/Socket résiste à
> tout kill...
> (re)merci.
Bonjour,
Cela indique simplement qu'un utilisateur connecté est dans la base dont
l'identifiant est dans la colonne dbid (hors master).
Cordialement,
LionelP
"Jean-Yves" wrote:
> Bonjour,
>
> J'ai un petit souci. Une application en .NET accède à une base de données
> SQLServer 2000 via ADO, en n'utilisant les ressources qu'en cas de besoin.
> Suite à une login form, je charge depuis le SGBD un profil et quelques infos
> que je stocke dans une classe "session". Ensuite, j'arrive dans une form type
> "modules autorisés", chaque module cliqué ouvrant une nouvelle form qui, en
> fonction de critères, ouvre une connexion, charge des données via une
> procédure stockée, puis referme la connexion et laisse le garbage collector
> libérer les ressources allouées. Tant que l'utilisateur n'agit pas, pas de
> connexion au serveur SQL.
> Or, je me retrouve pendant la durée de vie de l'application avec des
> connexions SQL dans le volet Activités d'Enterprise Manager (2, en général
> par client de cette application) et des verrous DB. Tout ce petit bestiaire
> s'évanouit dès qu'on termine l'application...
>
> a) Comme mes connexions sont encapsulées dans des Try...Finally, il est
> théoriquement impossible de laisser une connexion active. Comment cela se
> peut-il donc ?
> b) Que sont au juste ces verrous DB qui apparaissent ?
>
> Merci de m'aider, si vous le pouvez.
> Jean-Yves
>
> P.S: une connexion ouverte via Canaux nommés est-elle plus facilement
> "killable" qu'une autre ouverte à travers Socket TCP/IP ? J'ai le cas de
> figure et je ne comprends pas pourquoi une connexion Enterprise Manager se
> tue très bien avec son spid, alors qu'une connexion via ADO/Socket résiste à
> tout kill...
> (re)merci.
Merci pour la réponse.
OK pour le verrou DB. Mais j'aimerais quand même savoir (si c'est vrai
d'abord)pourquoi une cnx SQLEM est plus simple à tuer qu'une cnx .NET
provider ?
Ca m'intrigue, et pour des raisons de troubles de la maintenance nocturne
(base pas en mono-utilisateur), j'ai besoin de corriger ce problème assez
vîte.
Merci encore.
Jean-Yves
"" a écrit :
> Bonjour,
>
> Cela indique simplement qu'un utilisateur connecté est dans la base dont
> l'identifiant est dans la colonne dbid (hors master).
>
> Cordialement,
> LionelP
>
> "Jean-Yves" wrote:
>
> > Bonjour,
> >
> > J'ai un petit souci. Une application en .NET accède à une base de données
> > SQLServer 2000 via ADO, en n'utilisant les ressources qu'en cas de besoin.
> > Suite à une login form, je charge depuis le SGBD un profil et quelques infos
> > que je stocke dans une classe "session". Ensuite, j'arrive dans une form type
> > "modules autorisés", chaque module cliqué ouvrant une nouvelle form qui, en
> > fonction de critères, ouvre une connexion, charge des données via une
> > procédure stockée, puis referme la connexion et laisse le garbage collector
> > libérer les ressources allouées. Tant que l'utilisateur n'agit pas, pas de
> > connexion au serveur SQL.
> > Or, je me retrouve pendant la durée de vie de l'application avec des
> > connexions SQL dans le volet Activités d'Enterprise Manager (2, en général
> > par client de cette application) et des verrous DB. Tout ce petit bestiaire
> > s'évanouit dès qu'on termine l'application...
> >
> > a) Comme mes connexions sont encapsulées dans des Try...Finally, il est
> > théoriquement impossible de laisser une connexion active. Comment cela se
> > peut-il donc ?
> > b) Que sont au juste ces verrous DB qui apparaissent ?
> >
> > Merci de m'aider, si vous le pouvez.
> > Jean-Yves
> >
> > P.S: une connexion ouverte via Canaux nommés est-elle plus facilement
> > "killable" qu'une autre ouverte à travers Socket TCP/IP ? J'ai le cas de
> > figure et je ne comprends pas pourquoi une connexion Enterprise Manager se
> > tue très bien avec son spid, alors qu'une connexion via ADO/Socket résiste à
> > tout kill...
> > (re)merci.
Merci pour la réponse.
OK pour le verrou DB. Mais j'aimerais quand même savoir (si c'est vrai
d'abord)pourquoi une cnx SQLEM est plus simple à tuer qu'une cnx .NET
provider ?
Ca m'intrigue, et pour des raisons de troubles de la maintenance nocturne
(base pas en mono-utilisateur), j'ai besoin de corriger ce problème assez
vîte.
Merci encore.
Jean-Yves
"lionelp@online.microsoft.com" a écrit :
> Bonjour,
>
> Cela indique simplement qu'un utilisateur connecté est dans la base dont
> l'identifiant est dans la colonne dbid (hors master).
>
> Cordialement,
> LionelP
>
> "Jean-Yves" wrote:
>
> > Bonjour,
> >
> > J'ai un petit souci. Une application en .NET accède à une base de données
> > SQLServer 2000 via ADO, en n'utilisant les ressources qu'en cas de besoin.
> > Suite à une login form, je charge depuis le SGBD un profil et quelques infos
> > que je stocke dans une classe "session". Ensuite, j'arrive dans une form type
> > "modules autorisés", chaque module cliqué ouvrant une nouvelle form qui, en
> > fonction de critères, ouvre une connexion, charge des données via une
> > procédure stockée, puis referme la connexion et laisse le garbage collector
> > libérer les ressources allouées. Tant que l'utilisateur n'agit pas, pas de
> > connexion au serveur SQL.
> > Or, je me retrouve pendant la durée de vie de l'application avec des
> > connexions SQL dans le volet Activités d'Enterprise Manager (2, en général
> > par client de cette application) et des verrous DB. Tout ce petit bestiaire
> > s'évanouit dès qu'on termine l'application...
> >
> > a) Comme mes connexions sont encapsulées dans des Try...Finally, il est
> > théoriquement impossible de laisser une connexion active. Comment cela se
> > peut-il donc ?
> > b) Que sont au juste ces verrous DB qui apparaissent ?
> >
> > Merci de m'aider, si vous le pouvez.
> > Jean-Yves
> >
> > P.S: une connexion ouverte via Canaux nommés est-elle plus facilement
> > "killable" qu'une autre ouverte à travers Socket TCP/IP ? J'ai le cas de
> > figure et je ne comprends pas pourquoi une connexion Enterprise Manager se
> > tue très bien avec son spid, alors qu'une connexion via ADO/Socket résiste à
> > tout kill...
> > (re)merci.
Merci pour la réponse.
OK pour le verrou DB. Mais j'aimerais quand même savoir (si c'est vrai
d'abord)pourquoi une cnx SQLEM est plus simple à tuer qu'une cnx .NET
provider ?
Ca m'intrigue, et pour des raisons de troubles de la maintenance nocturne
(base pas en mono-utilisateur), j'ai besoin de corriger ce problème assez
vîte.
Merci encore.
Jean-Yves
"" a écrit :
> Bonjour,
>
> Cela indique simplement qu'un utilisateur connecté est dans la base dont
> l'identifiant est dans la colonne dbid (hors master).
>
> Cordialement,
> LionelP
>
> "Jean-Yves" wrote:
>
> > Bonjour,
> >
> > J'ai un petit souci. Une application en .NET accède à une base de données
> > SQLServer 2000 via ADO, en n'utilisant les ressources qu'en cas de besoin.
> > Suite à une login form, je charge depuis le SGBD un profil et quelques infos
> > que je stocke dans une classe "session". Ensuite, j'arrive dans une form type
> > "modules autorisés", chaque module cliqué ouvrant une nouvelle form qui, en
> > fonction de critères, ouvre une connexion, charge des données via une
> > procédure stockée, puis referme la connexion et laisse le garbage collector
> > libérer les ressources allouées. Tant que l'utilisateur n'agit pas, pas de
> > connexion au serveur SQL.
> > Or, je me retrouve pendant la durée de vie de l'application avec des
> > connexions SQL dans le volet Activités d'Enterprise Manager (2, en général
> > par client de cette application) et des verrous DB. Tout ce petit bestiaire
> > s'évanouit dès qu'on termine l'application...
> >
> > a) Comme mes connexions sont encapsulées dans des Try...Finally, il est
> > théoriquement impossible de laisser une connexion active. Comment cela se
> > peut-il donc ?
> > b) Que sont au juste ces verrous DB qui apparaissent ?
> >
> > Merci de m'aider, si vous le pouvez.
> > Jean-Yves
> >
> > P.S: une connexion ouverte via Canaux nommés est-elle plus facilement
> > "killable" qu'une autre ouverte à travers Socket TCP/IP ? J'ai le cas de
> > figure et je ne comprends pas pourquoi une connexion Enterprise Manager se
> > tue très bien avec son spid, alors qu'une connexion via ADO/Socket résiste à
> > tout kill...
> > (re)merci.
Bonjour,
Regarde si tes connexions .Net ont des transactions ouvertes, la fermeture
de la transaction mettra du temps d'autant plus grans que le rollback l'est.
Met une trace profiler qui te permettra de dire si c'est une connexion unique
qui dure dans le temps ou est-ce l'application qui se reconnecte et réutilise
le même spid.
Il n'y a a priori aucune raison pour qu'une connexion via .net ou autre soit
différente d'une autre.
Cordialement,
LionelP
"Jean-Yves" wrote:
> Merci pour la réponse.
>
> OK pour le verrou DB. Mais j'aimerais quand même savoir (si c'est vrai
> d'abord)pourquoi une cnx SQLEM est plus simple à tuer qu'une cnx .NET
> provider ?
> Ca m'intrigue, et pour des raisons de troubles de la maintenance nocturne
> (base pas en mono-utilisateur), j'ai besoin de corriger ce problème assez
> vîte.
>
> Merci encore.
> Jean-Yves
>
> "" a écrit :
>
> > Bonjour,
> >
> > Cela indique simplement qu'un utilisateur connecté est dans la base dont
> > l'identifiant est dans la colonne dbid (hors master).
> >
> > Cordialement,
> > LionelP
> >
> > "Jean-Yves" wrote:
> >
> > > Bonjour,
> > >
> > > J'ai un petit souci. Une application en .NET accède à une base de données
> > > SQLServer 2000 via ADO, en n'utilisant les ressources qu'en cas de besoin.
> > > Suite à une login form, je charge depuis le SGBD un profil et quelques infos
> > > que je stocke dans une classe "session". Ensuite, j'arrive dans une form type
> > > "modules autorisés", chaque module cliqué ouvrant une nouvelle form qui, en
> > > fonction de critères, ouvre une connexion, charge des données via une
> > > procédure stockée, puis referme la connexion et laisse le garbage collector
> > > libérer les ressources allouées. Tant que l'utilisateur n'agit pas, pas de
> > > connexion au serveur SQL.
> > > Or, je me retrouve pendant la durée de vie de l'application avec des
> > > connexions SQL dans le volet Activités d'Enterprise Manager (2, en général
> > > par client de cette application) et des verrous DB. Tout ce petit bestiaire
> > > s'évanouit dès qu'on termine l'application...
> > >
> > > a) Comme mes connexions sont encapsulées dans des Try...Finally, il est
> > > théoriquement impossible de laisser une connexion active. Comment cela se
> > > peut-il donc ?
> > > b) Que sont au juste ces verrous DB qui apparaissent ?
> > >
> > > Merci de m'aider, si vous le pouvez.
> > > Jean-Yves
> > >
> > > P.S: une connexion ouverte via Canaux nommés est-elle plus facilement
> > > "killable" qu'une autre ouverte à travers Socket TCP/IP ? J'ai le cas de
> > > figure et je ne comprends pas pourquoi une connexion Enterprise Manager se
> > > tue très bien avec son spid, alors qu'une connexion via ADO/Socket résiste à
> > > tout kill...
> > > (re)merci.
Bonjour,
Regarde si tes connexions .Net ont des transactions ouvertes, la fermeture
de la transaction mettra du temps d'autant plus grans que le rollback l'est.
Met une trace profiler qui te permettra de dire si c'est une connexion unique
qui dure dans le temps ou est-ce l'application qui se reconnecte et réutilise
le même spid.
Il n'y a a priori aucune raison pour qu'une connexion via .net ou autre soit
différente d'une autre.
Cordialement,
LionelP
"Jean-Yves" wrote:
> Merci pour la réponse.
>
> OK pour le verrou DB. Mais j'aimerais quand même savoir (si c'est vrai
> d'abord)pourquoi une cnx SQLEM est plus simple à tuer qu'une cnx .NET
> provider ?
> Ca m'intrigue, et pour des raisons de troubles de la maintenance nocturne
> (base pas en mono-utilisateur), j'ai besoin de corriger ce problème assez
> vîte.
>
> Merci encore.
> Jean-Yves
>
> "lionelp@online.microsoft.com" a écrit :
>
> > Bonjour,
> >
> > Cela indique simplement qu'un utilisateur connecté est dans la base dont
> > l'identifiant est dans la colonne dbid (hors master).
> >
> > Cordialement,
> > LionelP
> >
> > "Jean-Yves" wrote:
> >
> > > Bonjour,
> > >
> > > J'ai un petit souci. Une application en .NET accède à une base de données
> > > SQLServer 2000 via ADO, en n'utilisant les ressources qu'en cas de besoin.
> > > Suite à une login form, je charge depuis le SGBD un profil et quelques infos
> > > que je stocke dans une classe "session". Ensuite, j'arrive dans une form type
> > > "modules autorisés", chaque module cliqué ouvrant une nouvelle form qui, en
> > > fonction de critères, ouvre une connexion, charge des données via une
> > > procédure stockée, puis referme la connexion et laisse le garbage collector
> > > libérer les ressources allouées. Tant que l'utilisateur n'agit pas, pas de
> > > connexion au serveur SQL.
> > > Or, je me retrouve pendant la durée de vie de l'application avec des
> > > connexions SQL dans le volet Activités d'Enterprise Manager (2, en général
> > > par client de cette application) et des verrous DB. Tout ce petit bestiaire
> > > s'évanouit dès qu'on termine l'application...
> > >
> > > a) Comme mes connexions sont encapsulées dans des Try...Finally, il est
> > > théoriquement impossible de laisser une connexion active. Comment cela se
> > > peut-il donc ?
> > > b) Que sont au juste ces verrous DB qui apparaissent ?
> > >
> > > Merci de m'aider, si vous le pouvez.
> > > Jean-Yves
> > >
> > > P.S: une connexion ouverte via Canaux nommés est-elle plus facilement
> > > "killable" qu'une autre ouverte à travers Socket TCP/IP ? J'ai le cas de
> > > figure et je ne comprends pas pourquoi une connexion Enterprise Manager se
> > > tue très bien avec son spid, alors qu'une connexion via ADO/Socket résiste à
> > > tout kill...
> > > (re)merci.
Bonjour,
Regarde si tes connexions .Net ont des transactions ouvertes, la fermeture
de la transaction mettra du temps d'autant plus grans que le rollback l'est.
Met une trace profiler qui te permettra de dire si c'est une connexion unique
qui dure dans le temps ou est-ce l'application qui se reconnecte et réutilise
le même spid.
Il n'y a a priori aucune raison pour qu'une connexion via .net ou autre soit
différente d'une autre.
Cordialement,
LionelP
"Jean-Yves" wrote:
> Merci pour la réponse.
>
> OK pour le verrou DB. Mais j'aimerais quand même savoir (si c'est vrai
> d'abord)pourquoi une cnx SQLEM est plus simple à tuer qu'une cnx .NET
> provider ?
> Ca m'intrigue, et pour des raisons de troubles de la maintenance nocturne
> (base pas en mono-utilisateur), j'ai besoin de corriger ce problème assez
> vîte.
>
> Merci encore.
> Jean-Yves
>
> "" a écrit :
>
> > Bonjour,
> >
> > Cela indique simplement qu'un utilisateur connecté est dans la base dont
> > l'identifiant est dans la colonne dbid (hors master).
> >
> > Cordialement,
> > LionelP
> >
> > "Jean-Yves" wrote:
> >
> > > Bonjour,
> > >
> > > J'ai un petit souci. Une application en .NET accède à une base de données
> > > SQLServer 2000 via ADO, en n'utilisant les ressources qu'en cas de besoin.
> > > Suite à une login form, je charge depuis le SGBD un profil et quelques infos
> > > que je stocke dans une classe "session". Ensuite, j'arrive dans une form type
> > > "modules autorisés", chaque module cliqué ouvrant une nouvelle form qui, en
> > > fonction de critères, ouvre une connexion, charge des données via une
> > > procédure stockée, puis referme la connexion et laisse le garbage collector
> > > libérer les ressources allouées. Tant que l'utilisateur n'agit pas, pas de
> > > connexion au serveur SQL.
> > > Or, je me retrouve pendant la durée de vie de l'application avec des
> > > connexions SQL dans le volet Activités d'Enterprise Manager (2, en général
> > > par client de cette application) et des verrous DB. Tout ce petit bestiaire
> > > s'évanouit dès qu'on termine l'application...
> > >
> > > a) Comme mes connexions sont encapsulées dans des Try...Finally, il est
> > > théoriquement impossible de laisser une connexion active. Comment cela se
> > > peut-il donc ?
> > > b) Que sont au juste ces verrous DB qui apparaissent ?
> > >
> > > Merci de m'aider, si vous le pouvez.
> > > Jean-Yves
> > >
> > > P.S: une connexion ouverte via Canaux nommés est-elle plus facilement
> > > "killable" qu'une autre ouverte à travers Socket TCP/IP ? J'ai le cas de
> > > figure et je ne comprends pas pourquoi une connexion Enterprise Manager se
> > > tue très bien avec son spid, alors qu'une connexion via ADO/Socket résiste à
> > > tout kill...
> > > (re)merci.
Bonjour,
J'ai un petit souci. Une application en .NET accède à une base de données
SQLServer 2000 via ADO, en n'utilisant les ressources qu'en cas de besoin.
Suite à une login form, je charge depuis le SGBD un profil et quelques infos
que je stocke dans une classe "session". Ensuite, j'arrive dans une form type
"modules autorisés", chaque module cliqué ouvrant une nouvelle form qui, en
fonction de critères, ouvre une connexion, charge des données via une
procédure stockée, puis referme la connexion et laisse le garbage collector
libérer les ressources allouées. Tant que l'utilisateur n'agit pas, pas de
connexion au serveur SQL.
Or, je me retrouve pendant la durée de vie de l'application avec des
connexions SQL dans le volet Activités d'Enterprise Manager (2, en général
par client de cette application) et des verrous DB. Tout ce petit bestiaire
s'évanouit dès qu'on termine l'application...
a) Comme mes connexions sont encapsulées dans des Try...Finally, il est
théoriquement impossible de laisser une connexion active. Comment cela se
peut-il donc ?
b) Que sont au juste ces verrous DB qui apparaissent ?
Merci de m'aider, si vous le pouvez.
Jean-Yves
P.S: une connexion ouverte via Canaux nommés est-elle plus facilement
"killable" qu'une autre ouverte à travers Socket TCP/IP ? J'ai le cas de
figure et je ne comprends pas pourquoi une connexion Enterprise Manager se
tue très bien avec son spid, alors qu'une connexion via ADO/Socket résiste à
tout kill...
(re)merci.
Bonjour,
J'ai un petit souci. Une application en .NET accède à une base de données
SQLServer 2000 via ADO, en n'utilisant les ressources qu'en cas de besoin.
Suite à une login form, je charge depuis le SGBD un profil et quelques infos
que je stocke dans une classe "session". Ensuite, j'arrive dans une form type
"modules autorisés", chaque module cliqué ouvrant une nouvelle form qui, en
fonction de critères, ouvre une connexion, charge des données via une
procédure stockée, puis referme la connexion et laisse le garbage collector
libérer les ressources allouées. Tant que l'utilisateur n'agit pas, pas de
connexion au serveur SQL.
Or, je me retrouve pendant la durée de vie de l'application avec des
connexions SQL dans le volet Activités d'Enterprise Manager (2, en général
par client de cette application) et des verrous DB. Tout ce petit bestiaire
s'évanouit dès qu'on termine l'application...
a) Comme mes connexions sont encapsulées dans des Try...Finally, il est
théoriquement impossible de laisser une connexion active. Comment cela se
peut-il donc ?
b) Que sont au juste ces verrous DB qui apparaissent ?
Merci de m'aider, si vous le pouvez.
Jean-Yves
P.S: une connexion ouverte via Canaux nommés est-elle plus facilement
"killable" qu'une autre ouverte à travers Socket TCP/IP ? J'ai le cas de
figure et je ne comprends pas pourquoi une connexion Enterprise Manager se
tue très bien avec son spid, alors qu'une connexion via ADO/Socket résiste à
tout kill...
(re)merci.
Bonjour,
J'ai un petit souci. Une application en .NET accède à une base de données
SQLServer 2000 via ADO, en n'utilisant les ressources qu'en cas de besoin.
Suite à une login form, je charge depuis le SGBD un profil et quelques infos
que je stocke dans une classe "session". Ensuite, j'arrive dans une form type
"modules autorisés", chaque module cliqué ouvrant une nouvelle form qui, en
fonction de critères, ouvre une connexion, charge des données via une
procédure stockée, puis referme la connexion et laisse le garbage collector
libérer les ressources allouées. Tant que l'utilisateur n'agit pas, pas de
connexion au serveur SQL.
Or, je me retrouve pendant la durée de vie de l'application avec des
connexions SQL dans le volet Activités d'Enterprise Manager (2, en général
par client de cette application) et des verrous DB. Tout ce petit bestiaire
s'évanouit dès qu'on termine l'application...
a) Comme mes connexions sont encapsulées dans des Try...Finally, il est
théoriquement impossible de laisser une connexion active. Comment cela se
peut-il donc ?
b) Que sont au juste ces verrous DB qui apparaissent ?
Merci de m'aider, si vous le pouvez.
Jean-Yves
P.S: une connexion ouverte via Canaux nommés est-elle plus facilement
"killable" qu'une autre ouverte à travers Socket TCP/IP ? J'ai le cas de
figure et je ne comprends pas pourquoi une connexion Enterprise Manager se
tue très bien avec son spid, alors qu'une connexion via ADO/Socket résiste à
tout kill...
(re)merci.