Je travaille actuellement sur les transactions Sql Serveur (non
distribuées) et leurs comportements selon le niveau d'isolation choisi.
Je tente de reproduire dans ce domaine le fonctionnement par défaut
d'Oracle, et je bloque sur le problème suivant :
Avec un niveau d'isolation READ COMMITED, par défaut Oracle ne
"lock" aucune demande de lecture sur des enregistrements modifiés dans une
autre transaction (ou connexion) non encore validée. Mise à part les
modifications apportées dans la transaction en cours, le résultat d'un
SELECT retourne toujours la "version" des enregistrements validés. Ainsi, il
n'y a pas de blocage en lecture.
Sql Server 2000 fonctionne différemment avec le même niveau
d'isolation. Une requête SELECT est systématiquement bloquée si le jeu de
résultat doit contenir un enregistrement nouveau ou modifiée non encore
validé. Le mot clé READPAST dans la requête SELECT ne résout que le problème
lié aux nouveaux enregistrements, les renregistrements modifiés bloquent
toujours la demande de lecture !
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
Med Bouchenafa
Le sujet est matière a déclencher... une guerre. Kimberly a produit un article remarquable. http://www.microsoft.com/technet/prodtechnol/sql/2005/SQL05B.mspx
-- Bien cordialement Med Bouchenafa
"Christopher" a écrit dans le message de news:
Bonjour à tous,
Je travaille actuellement sur les transactions Sql Serveur (non distribuées) et leurs comportements selon le niveau d'isolation choisi. Je tente de reproduire dans ce domaine le fonctionnement par défaut d'Oracle, et je bloque sur le problème suivant : Avec un niveau d'isolation READ COMMITED, par défaut Oracle ne "lock" aucune demande de lecture sur des enregistrements modifiés dans une autre transaction (ou connexion) non encore validée. Mise à part les modifications apportées dans la transaction en cours, le résultat d'un SELECT retourne toujours la "version" des enregistrements validés. Ainsi, il n'y a pas de blocage en lecture. Sql Server 2000 fonctionne différemment avec le même niveau d'isolation. Une requête SELECT est systématiquement bloquée si le jeu de résultat doit contenir un enregistrement nouveau ou modifiée non encore validé. Le mot clé READPAST dans la requête SELECT ne résout que le problème lié aux nouveaux enregistrements, les renregistrements modifiés bloquent toujours la demande de lecture !
Y a-t-il une solution ?
Merci d'avance pour votre aide.
CIN.
Le sujet est matière a déclencher... une guerre.
Kimberly a produit un article remarquable.
http://www.microsoft.com/technet/prodtechnol/sql/2005/SQL05B.mspx
--
Bien cordialement
Med Bouchenafa
"Christopher" <VSIPUser@effect.fr> a écrit dans le message de news:
uLuSxZfWFHA.2944@TK2MSFTNGP10.phx.gbl...
Bonjour à tous,
Je travaille actuellement sur les transactions Sql Serveur (non
distribuées) et leurs comportements selon le niveau d'isolation choisi.
Je tente de reproduire dans ce domaine le fonctionnement par défaut
d'Oracle, et je bloque sur le problème suivant :
Avec un niveau d'isolation READ COMMITED, par défaut Oracle ne
"lock" aucune demande de lecture sur des enregistrements modifiés dans une
autre transaction (ou connexion) non encore validée. Mise à part les
modifications apportées dans la transaction en cours, le résultat d'un
SELECT retourne toujours la "version" des enregistrements validés. Ainsi,
il n'y a pas de blocage en lecture.
Sql Server 2000 fonctionne différemment avec le même niveau
d'isolation. Une requête SELECT est systématiquement bloquée si le jeu de
résultat doit contenir un enregistrement nouveau ou modifiée non encore
validé. Le mot clé READPAST dans la requête SELECT ne résout que le
problème lié aux nouveaux enregistrements, les renregistrements modifiés
bloquent toujours la demande de lecture !
Le sujet est matière a déclencher... une guerre. Kimberly a produit un article remarquable. http://www.microsoft.com/technet/prodtechnol/sql/2005/SQL05B.mspx
-- Bien cordialement Med Bouchenafa
"Christopher" a écrit dans le message de news:
Bonjour à tous,
Je travaille actuellement sur les transactions Sql Serveur (non distribuées) et leurs comportements selon le niveau d'isolation choisi. Je tente de reproduire dans ce domaine le fonctionnement par défaut d'Oracle, et je bloque sur le problème suivant : Avec un niveau d'isolation READ COMMITED, par défaut Oracle ne "lock" aucune demande de lecture sur des enregistrements modifiés dans une autre transaction (ou connexion) non encore validée. Mise à part les modifications apportées dans la transaction en cours, le résultat d'un SELECT retourne toujours la "version" des enregistrements validés. Ainsi, il n'y a pas de blocage en lecture. Sql Server 2000 fonctionne différemment avec le même niveau d'isolation. Une requête SELECT est systématiquement bloquée si le jeu de résultat doit contenir un enregistrement nouveau ou modifiée non encore validé. Le mot clé READPAST dans la requête SELECT ne résout que le problème lié aux nouveaux enregistrements, les renregistrements modifiés bloquent toujours la demande de lecture !
Y a-t-il une solution ?
Merci d'avance pour votre aide.
CIN.
Christopher
En effet. J'ai obtenu une réponse concordante sur le newsgroup sqlserver.programming. Merci pour l'information.
"Med Bouchenafa" a écrit dans le message de news: %
Le sujet est matière a déclencher... une guerre. Kimberly a produit un article remarquable. http://www.microsoft.com/technet/prodtechnol/sql/2005/SQL05B.mspx
-- Bien cordialement Med Bouchenafa
"Christopher" a écrit dans le message de news:
Bonjour à tous,
Je travaille actuellement sur les transactions Sql Serveur (non distribuées) et leurs comportements selon le niveau d'isolation choisi. Je tente de reproduire dans ce domaine le fonctionnement par défaut d'Oracle, et je bloque sur le problème suivant : Avec un niveau d'isolation READ COMMITED, par défaut Oracle ne "lock" aucune demande de lecture sur des enregistrements modifiés dans une autre transaction (ou connexion) non encore validée. Mise à part les modifications apportées dans la transaction en cours, le résultat d'un SELECT retourne toujours la "version" des enregistrements validés. Ainsi, il n'y a pas de blocage en lecture. Sql Server 2000 fonctionne différemment avec le même niveau d'isolation. Une requête SELECT est systématiquement bloquée si le jeu de résultat doit contenir un enregistrement nouveau ou modifiée non encore validé. Le mot clé READPAST dans la requête SELECT ne résout que le problème lié aux nouveaux enregistrements, les renregistrements modifiés bloquent toujours la demande de lecture !
Y a-t-il une solution ?
Merci d'avance pour votre aide.
CIN.
En effet. J'ai obtenu une réponse concordante sur le newsgroup
sqlserver.programming.
Merci pour l'information.
"Med Bouchenafa" <com.hotmail@bouchenafa> a écrit dans le message de news:
%23eMDEJqWFHA.1796@TK2MSFTNGP15.phx.gbl...
Le sujet est matière a déclencher... une guerre.
Kimberly a produit un article remarquable.
http://www.microsoft.com/technet/prodtechnol/sql/2005/SQL05B.mspx
--
Bien cordialement
Med Bouchenafa
"Christopher" <VSIPUser@effect.fr> a écrit dans le message de news:
uLuSxZfWFHA.2944@TK2MSFTNGP10.phx.gbl...
Bonjour à tous,
Je travaille actuellement sur les transactions Sql Serveur (non
distribuées) et leurs comportements selon le niveau d'isolation choisi.
Je tente de reproduire dans ce domaine le fonctionnement par défaut
d'Oracle, et je bloque sur le problème suivant :
Avec un niveau d'isolation READ COMMITED, par défaut Oracle ne
"lock" aucune demande de lecture sur des enregistrements modifiés dans
une autre transaction (ou connexion) non encore validée. Mise à part les
modifications apportées dans la transaction en cours, le résultat d'un
SELECT retourne toujours la "version" des enregistrements validés. Ainsi,
il n'y a pas de blocage en lecture.
Sql Server 2000 fonctionne différemment avec le même niveau
d'isolation. Une requête SELECT est systématiquement bloquée si le jeu de
résultat doit contenir un enregistrement nouveau ou modifiée non encore
validé. Le mot clé READPAST dans la requête SELECT ne résout que le
problème lié aux nouveaux enregistrements, les renregistrements modifiés
bloquent toujours la demande de lecture !
En effet. J'ai obtenu une réponse concordante sur le newsgroup sqlserver.programming. Merci pour l'information.
"Med Bouchenafa" a écrit dans le message de news: %
Le sujet est matière a déclencher... une guerre. Kimberly a produit un article remarquable. http://www.microsoft.com/technet/prodtechnol/sql/2005/SQL05B.mspx
-- Bien cordialement Med Bouchenafa
"Christopher" a écrit dans le message de news:
Bonjour à tous,
Je travaille actuellement sur les transactions Sql Serveur (non distribuées) et leurs comportements selon le niveau d'isolation choisi. Je tente de reproduire dans ce domaine le fonctionnement par défaut d'Oracle, et je bloque sur le problème suivant : Avec un niveau d'isolation READ COMMITED, par défaut Oracle ne "lock" aucune demande de lecture sur des enregistrements modifiés dans une autre transaction (ou connexion) non encore validée. Mise à part les modifications apportées dans la transaction en cours, le résultat d'un SELECT retourne toujours la "version" des enregistrements validés. Ainsi, il n'y a pas de blocage en lecture. Sql Server 2000 fonctionne différemment avec le même niveau d'isolation. Une requête SELECT est systématiquement bloquée si le jeu de résultat doit contenir un enregistrement nouveau ou modifiée non encore validé. Le mot clé READPAST dans la requête SELECT ne résout que le problème lié aux nouveaux enregistrements, les renregistrements modifiés bloquent toujours la demande de lecture !
