Depuis tout petit (enfin depuis 2 ans), lorsque j'utilise des curseurs, j'ai
pris l'habitude de les déclarer en INSENSITIVE :
DECLARE csrXXX INSENSITIVE CURSOR FOR
[...]
Sans comprendre à quoi ça sert ; l'aide de SQL Server me semble plutôt floue
là-dessus. Pour essayer, je n'ai pas mis insensitive et il m'est arrivé ceci
:
DB-Library: Unexpected EOF from SQL Server. General network error. Check
your documentation.
Net-Library error 10054: ConnectionCheckForData (CheckforData()).
DB-Library Process Dead - Connection Broken
Alors j'ai remis insensitive, mais je ne comprends toujours pas...
Quelqu'un pourrait-il m'expliquer les différences entre les curseurs
(insensitive, readonly, etc.)
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
David Brabant
"Stephane BOUVET" wrote
DECLARE csrXXX INSENSITIVE CURSOR FOR Sans comprendre à quoi ça sert ; l'aide de SQL Server me semble plutôt floue là-dessus.
Lorsque tu parcoures une table avec un curseur, il est évidemment probable que le contenu de cette même table soit modifié simultanément par d'autres utilisateurs/processes durant le temps nécessaire à effectuer ta boucle.
Lorsque tu déclares ton curseur "insensitive", un "snapshot" de la table est effectué dans tempdb et les données sont "fetchées" (ugh!) à partir de ce snapshot. Tu ne vois donc pas les éventuels updates effectués sur la table pendant le parcours de ton result set au travers de ton curseur.
Dans le cas où ton curseur n'est pas "insensitive", les données sont lues dans la table elle-même (pas de snapshot) et sont donc "sensibles" aux updates.
-- David
"Stephane BOUVET" <sga_bouvet@hotmail.com> wrote
DECLARE csrXXX INSENSITIVE CURSOR FOR
Sans comprendre à quoi ça sert ; l'aide de SQL Server
me semble plutôt floue là-dessus.
Lorsque tu parcoures une table avec un curseur, il est
évidemment probable que le contenu de cette même
table soit modifié simultanément par d'autres
utilisateurs/processes durant le temps nécessaire à
effectuer ta boucle.
Lorsque tu déclares ton curseur "insensitive", un
"snapshot" de la table est effectué dans tempdb
et les données sont "fetchées" (ugh!) à partir de
ce snapshot. Tu ne vois donc pas les éventuels
updates effectués sur la table pendant le parcours
de ton result set au travers de ton curseur.
Dans le cas où ton curseur n'est pas "insensitive",
les données sont lues dans la table elle-même (pas
de snapshot) et sont donc "sensibles" aux updates.
DECLARE csrXXX INSENSITIVE CURSOR FOR Sans comprendre à quoi ça sert ; l'aide de SQL Server me semble plutôt floue là-dessus.
Lorsque tu parcoures une table avec un curseur, il est évidemment probable que le contenu de cette même table soit modifié simultanément par d'autres utilisateurs/processes durant le temps nécessaire à effectuer ta boucle.
Lorsque tu déclares ton curseur "insensitive", un "snapshot" de la table est effectué dans tempdb et les données sont "fetchées" (ugh!) à partir de ce snapshot. Tu ne vois donc pas les éventuels updates effectués sur la table pendant le parcours de ton result set au travers de ton curseur.
Dans le cas où ton curseur n'est pas "insensitive", les données sont lues dans la table elle-même (pas de snapshot) et sont donc "sensibles" aux updates.
-- David
Stephane BOUVET
Merki bokou !! -- ~°~ -=S.T.E.I.N.=- ~°~ http://sbrnr.multimania.com "David Brabant" a écrit dans le message de news:blhau3$6qm$
"Stephane BOUVET" wrote
> DECLARE csrXXX INSENSITIVE CURSOR FOR > Sans comprendre à quoi ça sert ; l'aide de SQL Server > me semble plutôt floue là-dessus.
Lorsque tu parcoures une table avec un curseur, il est évidemment probable que le contenu de cette même table soit modifié simultanément par d'autres utilisateurs/processes durant le temps nécessaire à effectuer ta boucle.
Lorsque tu déclares ton curseur "insensitive", un "snapshot" de la table est effectué dans tempdb et les données sont "fetchées" (ugh!) à partir de ce snapshot. Tu ne vois donc pas les éventuels updates effectués sur la table pendant le parcours de ton result set au travers de ton curseur.
Dans le cas où ton curseur n'est pas "insensitive", les données sont lues dans la table elle-même (pas de snapshot) et sont donc "sensibles" aux updates.
-- David
Merki bokou !!
--
~°~ -=S.T.E.I.N.=- ~°~
http://sbrnr.multimania.com
"David Brabant" <david.brabant@qwanful.design.no.invalid> a écrit dans le
message de news:blhau3$6qm$1@news.mch.sbs.de...
"Stephane BOUVET" <sga_bouvet@hotmail.com> wrote
> DECLARE csrXXX INSENSITIVE CURSOR FOR
> Sans comprendre à quoi ça sert ; l'aide de SQL Server
> me semble plutôt floue là-dessus.
Lorsque tu parcoures une table avec un curseur, il est
évidemment probable que le contenu de cette même
table soit modifié simultanément par d'autres
utilisateurs/processes durant le temps nécessaire à
effectuer ta boucle.
Lorsque tu déclares ton curseur "insensitive", un
"snapshot" de la table est effectué dans tempdb
et les données sont "fetchées" (ugh!) à partir de
ce snapshot. Tu ne vois donc pas les éventuels
updates effectués sur la table pendant le parcours
de ton result set au travers de ton curseur.
Dans le cas où ton curseur n'est pas "insensitive",
les données sont lues dans la table elle-même (pas
de snapshot) et sont donc "sensibles" aux updates.
Merki bokou !! -- ~°~ -=S.T.E.I.N.=- ~°~ http://sbrnr.multimania.com "David Brabant" a écrit dans le message de news:blhau3$6qm$
"Stephane BOUVET" wrote
> DECLARE csrXXX INSENSITIVE CURSOR FOR > Sans comprendre à quoi ça sert ; l'aide de SQL Server > me semble plutôt floue là-dessus.
Lorsque tu parcoures une table avec un curseur, il est évidemment probable que le contenu de cette même table soit modifié simultanément par d'autres utilisateurs/processes durant le temps nécessaire à effectuer ta boucle.
Lorsque tu déclares ton curseur "insensitive", un "snapshot" de la table est effectué dans tempdb et les données sont "fetchées" (ugh!) à partir de ce snapshot. Tu ne vois donc pas les éventuels updates effectués sur la table pendant le parcours de ton result set au travers de ton curseur.
Dans le cas où ton curseur n'est pas "insensitive", les données sont lues dans la table elle-même (pas de snapshot) et sont donc "sensibles" aux updates.
