Bonjour
Je dois implémenter des verrous dans ma base de données. J'ai lu la
documentation SQL sur le sujet, et comme elle offre beaucoup de
possibilités
et qu'une telle action s'avère délicate, j'aimerais vous soumettre un
scénario simplifié d'implémentation de verrous afin d'avoir votre avis.
Contexte :
La base de données contient 3 tables (T1, T2 et T3) dont le schéma est
organisé en « flocon ».
Trois clients requièrent des ressources, soit pour faire une mise à jour,
soit pour lire les données.
Quotidiennement et à heure fixe, une synchronisation est faite sur
l'ensemble des tables.
Voici des actions simultanées possibles :
Action #1 - Client #1:
Update T1 WITH (UPDLOCK)
Set champ1 = @ch1
From T1
Where T1.id = @id
Update T2 WITH (UPDLOCK)..idem
Update T3 WITH (UPDLOCK). idem
Action #2 - Client #2:
Update T1 WITH (UPDLOCK). idem
Update T2 WITH (UPDLOCK). idem
Update T3 WITH (UPDLOCK). idem
Action #3 - Client #3 :
Select * from T1, T2, T3 WITH (READPAST | NOLOCK)
Action #4 - Synchronisation automatique des nouvelles données :
Insert into T1 values ..
Insert into T2 values ..
Insert into T3 values ..
1-Serait-ce un scénario envisageable? Quelles pourraient être les
problèmes
d'un tel contexte?
2-Doit-on utiliser le type de verrou READPAST ou NOLOCK lors de la lecture
dans ce contexte?
3-Doit-on mettre un verrou lors des transactions d'insertion?
Merci à l'avance pour votre aide.
Bonjour
Je dois implémenter des verrous dans ma base de données. J'ai lu la
documentation SQL sur le sujet, et comme elle offre beaucoup de
possibilités
et qu'une telle action s'avère délicate, j'aimerais vous soumettre un
scénario simplifié d'implémentation de verrous afin d'avoir votre avis.
Contexte :
La base de données contient 3 tables (T1, T2 et T3) dont le schéma est
organisé en « flocon ».
Trois clients requièrent des ressources, soit pour faire une mise à jour,
soit pour lire les données.
Quotidiennement et à heure fixe, une synchronisation est faite sur
l'ensemble des tables.
Voici des actions simultanées possibles :
Action #1 - Client #1:
Update T1 WITH (UPDLOCK)
Set champ1 = @ch1
From T1
Where T1.id = @id
Update T2 WITH (UPDLOCK)..idem
Update T3 WITH (UPDLOCK). idem
Action #2 - Client #2:
Update T1 WITH (UPDLOCK). idem
Update T2 WITH (UPDLOCK). idem
Update T3 WITH (UPDLOCK). idem
Action #3 - Client #3 :
Select * from T1, T2, T3 WITH (READPAST | NOLOCK)
Action #4 - Synchronisation automatique des nouvelles données :
Insert into T1 values ..
Insert into T2 values ..
Insert into T3 values ..
1-Serait-ce un scénario envisageable? Quelles pourraient être les
problèmes
d'un tel contexte?
2-Doit-on utiliser le type de verrou READPAST ou NOLOCK lors de la lecture
dans ce contexte?
3-Doit-on mettre un verrou lors des transactions d'insertion?
Merci à l'avance pour votre aide.
Bonjour
Je dois implémenter des verrous dans ma base de données. J'ai lu la
documentation SQL sur le sujet, et comme elle offre beaucoup de
possibilités
et qu'une telle action s'avère délicate, j'aimerais vous soumettre un
scénario simplifié d'implémentation de verrous afin d'avoir votre avis.
Contexte :
La base de données contient 3 tables (T1, T2 et T3) dont le schéma est
organisé en « flocon ».
Trois clients requièrent des ressources, soit pour faire une mise à jour,
soit pour lire les données.
Quotidiennement et à heure fixe, une synchronisation est faite sur
l'ensemble des tables.
Voici des actions simultanées possibles :
Action #1 - Client #1:
Update T1 WITH (UPDLOCK)
Set champ1 = @ch1
From T1
Where T1.id = @id
Update T2 WITH (UPDLOCK)..idem
Update T3 WITH (UPDLOCK). idem
Action #2 - Client #2:
Update T1 WITH (UPDLOCK). idem
Update T2 WITH (UPDLOCK). idem
Update T3 WITH (UPDLOCK). idem
Action #3 - Client #3 :
Select * from T1, T2, T3 WITH (READPAST | NOLOCK)
Action #4 - Synchronisation automatique des nouvelles données :
Insert into T1 values ..
Insert into T2 values ..
Insert into T3 values ..
1-Serait-ce un scénario envisageable? Quelles pourraient être les
problèmes
d'un tel contexte?
2-Doit-on utiliser le type de verrou READPAST ou NOLOCK lors de la lecture
dans ce contexte?
3-Doit-on mettre un verrou lors des transactions d'insertion?
Merci à l'avance pour votre aide.
Bonjour,
Pourquoi ne pas simplement gérer des transactions et laisser SQL gérés ses
verrous ?
Lors d'un INSERT, pas besoin de verrous.
----------------------------------------------------------------------
Philippe TROTIN - Microsoft Service France
"carjo12" wrote in message
news:
> Bonjour
>
> Je dois implémenter des verrous dans ma base de données. J'ai lu la
> documentation SQL sur le sujet, et comme elle offre beaucoup de
> possibilités
> et qu'une telle action s'avère délicate, j'aimerais vous soumettre un
> scénario simplifié d'implémentation de verrous afin d'avoir votre avis.
>
> Contexte :
>
> La base de données contient 3 tables (T1, T2 et T3) dont le schéma est
> organisé en « flocon ».
> Trois clients requièrent des ressources, soit pour faire une mise à jour,
> soit pour lire les données.
> Quotidiennement et à heure fixe, une synchronisation est faite sur
> l'ensemble des tables.
>
> Voici des actions simultanées possibles :
>
> Action #1 - Client #1:
>
> Update T1 WITH (UPDLOCK)
> Set champ1 = @ch1
> From T1
> Where T1.id = @id
>
> Update T2 WITH (UPDLOCK)..idem
> Update T3 WITH (UPDLOCK). idem
>
> Action #2 - Client #2:
>
> Update T1 WITH (UPDLOCK). idem
> Update T2 WITH (UPDLOCK). idem
> Update T3 WITH (UPDLOCK). idem
>
> Action #3 - Client #3 :
>
> Select * from T1, T2, T3 WITH (READPAST | NOLOCK)
>
> Action #4 - Synchronisation automatique des nouvelles données :
>
> Insert into T1 values ..
> Insert into T2 values ..
> Insert into T3 values ..
>
> 1-Serait-ce un scénario envisageable? Quelles pourraient être les
> problèmes
> d'un tel contexte?
>
> 2-Doit-on utiliser le type de verrou READPAST ou NOLOCK lors de la lecture
> dans ce contexte?
>
> 3-Doit-on mettre un verrou lors des transactions d'insertion?
>
> Merci à l'avance pour votre aide.
>
>
>
>
>
>
>
>
>
Bonjour,
Pourquoi ne pas simplement gérer des transactions et laisser SQL gérés ses
verrous ?
Lors d'un INSERT, pas besoin de verrous.
----------------------------------------------------------------------
Philippe TROTIN - Microsoft Service France
"carjo12" <carjo12@discussions.microsoft.com> wrote in message
news:97A1CFCB-7598-47B6-8317-CBBBEB686F77@microsoft.com...
> Bonjour
>
> Je dois implémenter des verrous dans ma base de données. J'ai lu la
> documentation SQL sur le sujet, et comme elle offre beaucoup de
> possibilités
> et qu'une telle action s'avère délicate, j'aimerais vous soumettre un
> scénario simplifié d'implémentation de verrous afin d'avoir votre avis.
>
> Contexte :
>
> La base de données contient 3 tables (T1, T2 et T3) dont le schéma est
> organisé en « flocon ».
> Trois clients requièrent des ressources, soit pour faire une mise à jour,
> soit pour lire les données.
> Quotidiennement et à heure fixe, une synchronisation est faite sur
> l'ensemble des tables.
>
> Voici des actions simultanées possibles :
>
> Action #1 - Client #1:
>
> Update T1 WITH (UPDLOCK)
> Set champ1 = @ch1
> From T1
> Where T1.id = @id
>
> Update T2 WITH (UPDLOCK)..idem
> Update T3 WITH (UPDLOCK). idem
>
> Action #2 - Client #2:
>
> Update T1 WITH (UPDLOCK). idem
> Update T2 WITH (UPDLOCK). idem
> Update T3 WITH (UPDLOCK). idem
>
> Action #3 - Client #3 :
>
> Select * from T1, T2, T3 WITH (READPAST | NOLOCK)
>
> Action #4 - Synchronisation automatique des nouvelles données :
>
> Insert into T1 values ..
> Insert into T2 values ..
> Insert into T3 values ..
>
> 1-Serait-ce un scénario envisageable? Quelles pourraient être les
> problèmes
> d'un tel contexte?
>
> 2-Doit-on utiliser le type de verrou READPAST ou NOLOCK lors de la lecture
> dans ce contexte?
>
> 3-Doit-on mettre un verrou lors des transactions d'insertion?
>
> Merci à l'avance pour votre aide.
>
>
>
>
>
>
>
>
>
Bonjour,
Pourquoi ne pas simplement gérer des transactions et laisser SQL gérés ses
verrous ?
Lors d'un INSERT, pas besoin de verrous.
----------------------------------------------------------------------
Philippe TROTIN - Microsoft Service France
"carjo12" wrote in message
news:
> Bonjour
>
> Je dois implémenter des verrous dans ma base de données. J'ai lu la
> documentation SQL sur le sujet, et comme elle offre beaucoup de
> possibilités
> et qu'une telle action s'avère délicate, j'aimerais vous soumettre un
> scénario simplifié d'implémentation de verrous afin d'avoir votre avis.
>
> Contexte :
>
> La base de données contient 3 tables (T1, T2 et T3) dont le schéma est
> organisé en « flocon ».
> Trois clients requièrent des ressources, soit pour faire une mise à jour,
> soit pour lire les données.
> Quotidiennement et à heure fixe, une synchronisation est faite sur
> l'ensemble des tables.
>
> Voici des actions simultanées possibles :
>
> Action #1 - Client #1:
>
> Update T1 WITH (UPDLOCK)
> Set champ1 = @ch1
> From T1
> Where T1.id = @id
>
> Update T2 WITH (UPDLOCK)..idem
> Update T3 WITH (UPDLOCK). idem
>
> Action #2 - Client #2:
>
> Update T1 WITH (UPDLOCK). idem
> Update T2 WITH (UPDLOCK). idem
> Update T3 WITH (UPDLOCK). idem
>
> Action #3 - Client #3 :
>
> Select * from T1, T2, T3 WITH (READPAST | NOLOCK)
>
> Action #4 - Synchronisation automatique des nouvelles données :
>
> Insert into T1 values ..
> Insert into T2 values ..
> Insert into T3 values ..
>
> 1-Serait-ce un scénario envisageable? Quelles pourraient être les
> problèmes
> d'un tel contexte?
>
> 2-Doit-on utiliser le type de verrou READPAST ou NOLOCK lors de la lecture
> dans ce contexte?
>
> 3-Doit-on mettre un verrou lors des transactions d'insertion?
>
> Merci à l'avance pour votre aide.
>
>
>
>
>
>
>
>
>
Dans ce cas, qu'est-ce qui arrive si 2 personnes effectuent une mise à jour
en même temps, sur la même ligne?
Merci.
"Philippe T [MS]" a écrit :Bonjour,
Pourquoi ne pas simplement gérer des transactions et laisser SQL gérés ses
verrous ?
Lors d'un INSERT, pas besoin de verrous.
----------------------------------------------------------------------
Philippe TROTIN - Microsoft Service France
"carjo12" wrote in message
news:Bonjour
Je dois implémenter des verrous dans ma base de données. J'ai lu la
documentation SQL sur le sujet, et comme elle offre beaucoup de
possibilités
et qu'une telle action s'avère délicate, j'aimerais vous soumettre un
scénario simplifié d'implémentation de verrous afin d'avoir votre avis.
Contexte :
La base de données contient 3 tables (T1, T2 et T3) dont le schéma est
organisé en « flocon ».
Trois clients requièrent des ressources, soit pour faire une mise à jour,
soit pour lire les données.
Quotidiennement et à heure fixe, une synchronisation est faite sur
l'ensemble des tables.
Voici des actions simultanées possibles :
Action #1 - Client #1:
Update T1 WITH (UPDLOCK)
Set champ1 = @ch1
From T1
Where T1.id = @id
Update T2 WITH (UPDLOCK)..idem
Update T3 WITH (UPDLOCK). idem
Action #2 - Client #2:
Update T1 WITH (UPDLOCK). idem
Update T2 WITH (UPDLOCK). idem
Update T3 WITH (UPDLOCK). idem
Action #3 - Client #3 :
Select * from T1, T2, T3 WITH (READPAST | NOLOCK)
Action #4 - Synchronisation automatique des nouvelles données :
Insert into T1 values ..
Insert into T2 values ..
Insert into T3 values ..
1-Serait-ce un scénario envisageable? Quelles pourraient être les
problèmes
d'un tel contexte?
2-Doit-on utiliser le type de verrou READPAST ou NOLOCK lors de la lecture
dans ce contexte?
3-Doit-on mettre un verrou lors des transactions d'insertion?
Merci à l'avance pour votre aide.
Dans ce cas, qu'est-ce qui arrive si 2 personnes effectuent une mise à jour
en même temps, sur la même ligne?
Merci.
"Philippe T [MS]" a écrit :
Bonjour,
Pourquoi ne pas simplement gérer des transactions et laisser SQL gérés ses
verrous ?
Lors d'un INSERT, pas besoin de verrous.
----------------------------------------------------------------------
Philippe TROTIN - Microsoft Service France
"carjo12" <carjo12@discussions.microsoft.com> wrote in message
news:97A1CFCB-7598-47B6-8317-CBBBEB686F77@microsoft.com...
Bonjour
Je dois implémenter des verrous dans ma base de données. J'ai lu la
documentation SQL sur le sujet, et comme elle offre beaucoup de
possibilités
et qu'une telle action s'avère délicate, j'aimerais vous soumettre un
scénario simplifié d'implémentation de verrous afin d'avoir votre avis.
Contexte :
La base de données contient 3 tables (T1, T2 et T3) dont le schéma est
organisé en « flocon ».
Trois clients requièrent des ressources, soit pour faire une mise à jour,
soit pour lire les données.
Quotidiennement et à heure fixe, une synchronisation est faite sur
l'ensemble des tables.
Voici des actions simultanées possibles :
Action #1 - Client #1:
Update T1 WITH (UPDLOCK)
Set champ1 = @ch1
From T1
Where T1.id = @id
Update T2 WITH (UPDLOCK)..idem
Update T3 WITH (UPDLOCK). idem
Action #2 - Client #2:
Update T1 WITH (UPDLOCK). idem
Update T2 WITH (UPDLOCK). idem
Update T3 WITH (UPDLOCK). idem
Action #3 - Client #3 :
Select * from T1, T2, T3 WITH (READPAST | NOLOCK)
Action #4 - Synchronisation automatique des nouvelles données :
Insert into T1 values ..
Insert into T2 values ..
Insert into T3 values ..
1-Serait-ce un scénario envisageable? Quelles pourraient être les
problèmes
d'un tel contexte?
2-Doit-on utiliser le type de verrou READPAST ou NOLOCK lors de la lecture
dans ce contexte?
3-Doit-on mettre un verrou lors des transactions d'insertion?
Merci à l'avance pour votre aide.
Dans ce cas, qu'est-ce qui arrive si 2 personnes effectuent une mise à jour
en même temps, sur la même ligne?
Merci.
"Philippe T [MS]" a écrit :Bonjour,
Pourquoi ne pas simplement gérer des transactions et laisser SQL gérés ses
verrous ?
Lors d'un INSERT, pas besoin de verrous.
----------------------------------------------------------------------
Philippe TROTIN - Microsoft Service France
"carjo12" wrote in message
news:Bonjour
Je dois implémenter des verrous dans ma base de données. J'ai lu la
documentation SQL sur le sujet, et comme elle offre beaucoup de
possibilités
et qu'une telle action s'avère délicate, j'aimerais vous soumettre un
scénario simplifié d'implémentation de verrous afin d'avoir votre avis.
Contexte :
La base de données contient 3 tables (T1, T2 et T3) dont le schéma est
organisé en « flocon ».
Trois clients requièrent des ressources, soit pour faire une mise à jour,
soit pour lire les données.
Quotidiennement et à heure fixe, une synchronisation est faite sur
l'ensemble des tables.
Voici des actions simultanées possibles :
Action #1 - Client #1:
Update T1 WITH (UPDLOCK)
Set champ1 = @ch1
From T1
Where T1.id = @id
Update T2 WITH (UPDLOCK)..idem
Update T3 WITH (UPDLOCK). idem
Action #2 - Client #2:
Update T1 WITH (UPDLOCK). idem
Update T2 WITH (UPDLOCK). idem
Update T3 WITH (UPDLOCK). idem
Action #3 - Client #3 :
Select * from T1, T2, T3 WITH (READPAST | NOLOCK)
Action #4 - Synchronisation automatique des nouvelles données :
Insert into T1 values ..
Insert into T2 values ..
Insert into T3 values ..
1-Serait-ce un scénario envisageable? Quelles pourraient être les
problèmes
d'un tel contexte?
2-Doit-on utiliser le type de verrou READPAST ou NOLOCK lors de la lecture
dans ce contexte?
3-Doit-on mettre un verrou lors des transactions d'insertion?
Merci à l'avance pour votre aide.
Tout dépend de la façons dont cette MAJ est faites.
Si c'est à travers un curseur (par exemple en client connecté tel que VB,
Delphi, C++, C#...) alors l'un des deux sera rejeté (verrous optimiste) avec un
message du genre : la version de la ligne considérée à changée, impossiblme de
mettre à jour.
Si client déconnecté alors les 2 maj se feront successivement.
Ne jamais utiliser directement les verrous, c'est comme cela que l'on tue une
base de données.
Lire sur les transactions en général :
http://sqlpro.developpez.com/cours/sqlaz/techniques/#L1
Sur les verrous SQL Server et les transactions SQL Server :
http://sqlpro.developpez.com/cours/sqlserver/transactsql/#L4.5
A +
--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************
carjo12 a écrit:
> Dans ce cas, qu'est-ce qui arrive si 2 personnes effectuent une mise à jour
> en même temps, sur la même ligne?
>
> Merci.
>
> "Philippe T [MS]" a écrit :
>
>
>>Bonjour,
>>
>>Pourquoi ne pas simplement gérer des transactions et laisser SQL gérés ses
>>verrous ?
>>
>>Lors d'un INSERT, pas besoin de verrous.
>>
>>----------------------------------------------------------------------
>>Philippe TROTIN - Microsoft Service France
>>
>>"carjo12" wrote in message
>>news:
>>
>>>Bonjour
>>>
>>>Je dois implémenter des verrous dans ma base de données. J'ai lu la
>>>documentation SQL sur le sujet, et comme elle offre beaucoup de
>>>possibilités
>>>et qu'une telle action s'avère délicate, j'aimerais vous soumettre un
>>>scénario simplifié d'implémentation de verrous afin d'avoir votre avis.
>>>
>>>Contexte :
>>>
>>>La base de données contient 3 tables (T1, T2 et T3) dont le schéma est
>>>organisé en « flocon ».
>>>Trois clients requièrent des ressources, soit pour faire une mise à jour,
>>>soit pour lire les données.
>>>Quotidiennement et à heure fixe, une synchronisation est faite sur
>>>l'ensemble des tables.
>>>
>>>Voici des actions simultanées possibles :
>>>
>>>Action #1 - Client #1:
>>>
>>>Update T1 WITH (UPDLOCK)
>>>Set champ1 = @ch1
>>>From T1
>>>Where T1.id = @id
>>>
>>>Update T2 WITH (UPDLOCK)..idem
>>>Update T3 WITH (UPDLOCK). idem
>>>
>>>Action #2 - Client #2:
>>>
>>>Update T1 WITH (UPDLOCK). idem
>>>Update T2 WITH (UPDLOCK). idem
>>>Update T3 WITH (UPDLOCK). idem
>>>
>>>Action #3 - Client #3 :
>>>
>>>Select * from T1, T2, T3 WITH (READPAST | NOLOCK)
>>>
>>>Action #4 - Synchronisation automatique des nouvelles données :
>>>
>>>Insert into T1 values ..
>>>Insert into T2 values ..
>>>Insert into T3 values ..
>>>
>>>1-Serait-ce un scénario envisageable? Quelles pourraient être les
>>>problèmes
>>>d'un tel contexte?
>>>
>>>2-Doit-on utiliser le type de verrou READPAST ou NOLOCK lors de la lecture
>>>dans ce contexte?
>>>
>>>3-Doit-on mettre un verrou lors des transactions d'insertion?
>>>
>>>Merci à l'avance pour votre aide.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
Tout dépend de la façons dont cette MAJ est faites.
Si c'est à travers un curseur (par exemple en client connecté tel que VB,
Delphi, C++, C#...) alors l'un des deux sera rejeté (verrous optimiste) avec un
message du genre : la version de la ligne considérée à changée, impossiblme de
mettre à jour.
Si client déconnecté alors les 2 maj se feront successivement.
Ne jamais utiliser directement les verrous, c'est comme cela que l'on tue une
base de données.
Lire sur les transactions en général :
http://sqlpro.developpez.com/cours/sqlaz/techniques/#L1
Sur les verrous SQL Server et les transactions SQL Server :
http://sqlpro.developpez.com/cours/sqlserver/transactsql/#L4.5
A +
--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************
carjo12 a écrit:
> Dans ce cas, qu'est-ce qui arrive si 2 personnes effectuent une mise à jour
> en même temps, sur la même ligne?
>
> Merci.
>
> "Philippe T [MS]" a écrit :
>
>
>>Bonjour,
>>
>>Pourquoi ne pas simplement gérer des transactions et laisser SQL gérés ses
>>verrous ?
>>
>>Lors d'un INSERT, pas besoin de verrous.
>>
>>----------------------------------------------------------------------
>>Philippe TROTIN - Microsoft Service France
>>
>>"carjo12" <carjo12@discussions.microsoft.com> wrote in message
>>news:97A1CFCB-7598-47B6-8317-CBBBEB686F77@microsoft.com...
>>
>>>Bonjour
>>>
>>>Je dois implémenter des verrous dans ma base de données. J'ai lu la
>>>documentation SQL sur le sujet, et comme elle offre beaucoup de
>>>possibilités
>>>et qu'une telle action s'avère délicate, j'aimerais vous soumettre un
>>>scénario simplifié d'implémentation de verrous afin d'avoir votre avis.
>>>
>>>Contexte :
>>>
>>>La base de données contient 3 tables (T1, T2 et T3) dont le schéma est
>>>organisé en « flocon ».
>>>Trois clients requièrent des ressources, soit pour faire une mise à jour,
>>>soit pour lire les données.
>>>Quotidiennement et à heure fixe, une synchronisation est faite sur
>>>l'ensemble des tables.
>>>
>>>Voici des actions simultanées possibles :
>>>
>>>Action #1 - Client #1:
>>>
>>>Update T1 WITH (UPDLOCK)
>>>Set champ1 = @ch1
>>>From T1
>>>Where T1.id = @id
>>>
>>>Update T2 WITH (UPDLOCK)..idem
>>>Update T3 WITH (UPDLOCK). idem
>>>
>>>Action #2 - Client #2:
>>>
>>>Update T1 WITH (UPDLOCK). idem
>>>Update T2 WITH (UPDLOCK). idem
>>>Update T3 WITH (UPDLOCK). idem
>>>
>>>Action #3 - Client #3 :
>>>
>>>Select * from T1, T2, T3 WITH (READPAST | NOLOCK)
>>>
>>>Action #4 - Synchronisation automatique des nouvelles données :
>>>
>>>Insert into T1 values ..
>>>Insert into T2 values ..
>>>Insert into T3 values ..
>>>
>>>1-Serait-ce un scénario envisageable? Quelles pourraient être les
>>>problèmes
>>>d'un tel contexte?
>>>
>>>2-Doit-on utiliser le type de verrou READPAST ou NOLOCK lors de la lecture
>>>dans ce contexte?
>>>
>>>3-Doit-on mettre un verrou lors des transactions d'insertion?
>>>
>>>Merci à l'avance pour votre aide.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
Tout dépend de la façons dont cette MAJ est faites.
Si c'est à travers un curseur (par exemple en client connecté tel que VB,
Delphi, C++, C#...) alors l'un des deux sera rejeté (verrous optimiste) avec un
message du genre : la version de la ligne considérée à changée, impossiblme de
mettre à jour.
Si client déconnecté alors les 2 maj se feront successivement.
Ne jamais utiliser directement les verrous, c'est comme cela que l'on tue une
base de données.
Lire sur les transactions en général :
http://sqlpro.developpez.com/cours/sqlaz/techniques/#L1
Sur les verrous SQL Server et les transactions SQL Server :
http://sqlpro.developpez.com/cours/sqlserver/transactsql/#L4.5
A +
--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************
carjo12 a écrit:
> Dans ce cas, qu'est-ce qui arrive si 2 personnes effectuent une mise à jour
> en même temps, sur la même ligne?
>
> Merci.
>
> "Philippe T [MS]" a écrit :
>
>
>>Bonjour,
>>
>>Pourquoi ne pas simplement gérer des transactions et laisser SQL gérés ses
>>verrous ?
>>
>>Lors d'un INSERT, pas besoin de verrous.
>>
>>----------------------------------------------------------------------
>>Philippe TROTIN - Microsoft Service France
>>
>>"carjo12" wrote in message
>>news:
>>
>>>Bonjour
>>>
>>>Je dois implémenter des verrous dans ma base de données. J'ai lu la
>>>documentation SQL sur le sujet, et comme elle offre beaucoup de
>>>possibilités
>>>et qu'une telle action s'avère délicate, j'aimerais vous soumettre un
>>>scénario simplifié d'implémentation de verrous afin d'avoir votre avis.
>>>
>>>Contexte :
>>>
>>>La base de données contient 3 tables (T1, T2 et T3) dont le schéma est
>>>organisé en « flocon ».
>>>Trois clients requièrent des ressources, soit pour faire une mise à jour,
>>>soit pour lire les données.
>>>Quotidiennement et à heure fixe, une synchronisation est faite sur
>>>l'ensemble des tables.
>>>
>>>Voici des actions simultanées possibles :
>>>
>>>Action #1 - Client #1:
>>>
>>>Update T1 WITH (UPDLOCK)
>>>Set champ1 = @ch1
>>>From T1
>>>Where T1.id = @id
>>>
>>>Update T2 WITH (UPDLOCK)..idem
>>>Update T3 WITH (UPDLOCK). idem
>>>
>>>Action #2 - Client #2:
>>>
>>>Update T1 WITH (UPDLOCK). idem
>>>Update T2 WITH (UPDLOCK). idem
>>>Update T3 WITH (UPDLOCK). idem
>>>
>>>Action #3 - Client #3 :
>>>
>>>Select * from T1, T2, T3 WITH (READPAST | NOLOCK)
>>>
>>>Action #4 - Synchronisation automatique des nouvelles données :
>>>
>>>Insert into T1 values ..
>>>Insert into T2 values ..
>>>Insert into T3 values ..
>>>
>>>1-Serait-ce un scénario envisageable? Quelles pourraient être les
>>>problèmes
>>>d'un tel contexte?
>>>
>>>2-Doit-on utiliser le type de verrou READPAST ou NOLOCK lors de la lecture
>>>dans ce contexte?
>>>
>>>3-Doit-on mettre un verrou lors des transactions d'insertion?
>>>
>>>Merci à l'avance pour votre aide.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
Merci beaucoup pour les informations et les liens. Toutefois, pourriez-vous
me préciser certains points que vous avez mentionnés, svp?
Les clients sont connectés en SQL. La MAJ est très simple et standard, sans
curseur, du genre:
Update T1
Set champ1 = @ch1
From T1
Where T1.id = @id
1 - Qu'entendez-vous par "client déconnecté"? Si les MAJ se font
successivement, alors il n'y a pas de problèmes de concurrence ?
2 - Si j'ai bien compris votre message, avec la façon décrite plus haut de
faire le Update,
a - SQL posera des verrous pessimistes, et le succès de la transaction
sera assuré
b - Il est préférable de ne pas "personnaliser" l'implémentation de
verrous dans la BD...
Merci de vos précisions.
"Fred BROUARD" a écrit :Tout dépend de la façons dont cette MAJ est faites.
Si c'est à travers un curseur (par exemple en client connecté tel que VB,
Delphi, C++, C#...) alors l'un des deux sera rejeté (verrous optimiste) avec un
message du genre : la version de la ligne considérée à changée, impossiblme de
mettre à jour.
Si client déconnecté alors les 2 maj se feront successivement.
Ne jamais utiliser directement les verrous, c'est comme cela que l'on tue une
base de données.
Lire sur les transactions en général :
http://sqlpro.developpez.com/cours/sqlaz/techniques/#L1
Sur les verrous SQL Server et les transactions SQL Server :
http://sqlpro.developpez.com/cours/sqlserver/transactsql/#L4.5
A +
--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************
carjo12 a écrit:Dans ce cas, qu'est-ce qui arrive si 2 personnes effectuent une mise à jour
en même temps, sur la même ligne?
Merci.
"Philippe T [MS]" a écrit :Bonjour,
Pourquoi ne pas simplement gérer des transactions et laisser SQL gérés ses
verrous ?
Lors d'un INSERT, pas besoin de verrous.
----------------------------------------------------------------------
Philippe TROTIN - Microsoft Service France
"carjo12" wrote in message
news:Bonjour
Je dois implémenter des verrous dans ma base de données. J'ai lu la
documentation SQL sur le sujet, et comme elle offre beaucoup de
possibilités
et qu'une telle action s'avère délicate, j'aimerais vous soumettre un
scénario simplifié d'implémentation de verrous afin d'avoir votre avis.
Contexte :
La base de données contient 3 tables (T1, T2 et T3) dont le schéma est
organisé en « flocon ».
Trois clients requièrent des ressources, soit pour faire une mise à jour,
soit pour lire les données.
Quotidiennement et à heure fixe, une synchronisation est faite sur
l'ensemble des tables.
Voici des actions simultanées possibles :
Action #1 - Client #1:
Update T1 WITH (UPDLOCK)
Set champ1 = @ch1From T1Where T1.id = @id
Update T2 WITH (UPDLOCK)..idem
Update T3 WITH (UPDLOCK). idem
Action #2 - Client #2:
Update T1 WITH (UPDLOCK). idem
Update T2 WITH (UPDLOCK). idem
Update T3 WITH (UPDLOCK). idem
Action #3 - Client #3 :
Select * from T1, T2, T3 WITH (READPAST | NOLOCK)
Action #4 - Synchronisation automatique des nouvelles données :
Insert into T1 values ..
Insert into T2 values ..
Insert into T3 values ..
1-Serait-ce un scénario envisageable? Quelles pourraient être les
problèmes
d'un tel contexte?
2-Doit-on utiliser le type de verrou READPAST ou NOLOCK lors de la lecture
dans ce contexte?
3-Doit-on mettre un verrou lors des transactions d'insertion?
Merci à l'avance pour votre aide.
Merci beaucoup pour les informations et les liens. Toutefois, pourriez-vous
me préciser certains points que vous avez mentionnés, svp?
Les clients sont connectés en SQL. La MAJ est très simple et standard, sans
curseur, du genre:
Update T1
Set champ1 = @ch1
From T1
Where T1.id = @id
1 - Qu'entendez-vous par "client déconnecté"? Si les MAJ se font
successivement, alors il n'y a pas de problèmes de concurrence ?
2 - Si j'ai bien compris votre message, avec la façon décrite plus haut de
faire le Update,
a - SQL posera des verrous pessimistes, et le succès de la transaction
sera assuré
b - Il est préférable de ne pas "personnaliser" l'implémentation de
verrous dans la BD...
Merci de vos précisions.
"Fred BROUARD" a écrit :
Tout dépend de la façons dont cette MAJ est faites.
Si c'est à travers un curseur (par exemple en client connecté tel que VB,
Delphi, C++, C#...) alors l'un des deux sera rejeté (verrous optimiste) avec un
message du genre : la version de la ligne considérée à changée, impossiblme de
mettre à jour.
Si client déconnecté alors les 2 maj se feront successivement.
Ne jamais utiliser directement les verrous, c'est comme cela que l'on tue une
base de données.
Lire sur les transactions en général :
http://sqlpro.developpez.com/cours/sqlaz/techniques/#L1
Sur les verrous SQL Server et les transactions SQL Server :
http://sqlpro.developpez.com/cours/sqlserver/transactsql/#L4.5
A +
--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************
carjo12 a écrit:
Dans ce cas, qu'est-ce qui arrive si 2 personnes effectuent une mise à jour
en même temps, sur la même ligne?
Merci.
"Philippe T [MS]" a écrit :
Bonjour,
Pourquoi ne pas simplement gérer des transactions et laisser SQL gérés ses
verrous ?
Lors d'un INSERT, pas besoin de verrous.
----------------------------------------------------------------------
Philippe TROTIN - Microsoft Service France
"carjo12" <carjo12@discussions.microsoft.com> wrote in message
news:97A1CFCB-7598-47B6-8317-CBBBEB686F77@microsoft.com...
Bonjour
Je dois implémenter des verrous dans ma base de données. J'ai lu la
documentation SQL sur le sujet, et comme elle offre beaucoup de
possibilités
et qu'une telle action s'avère délicate, j'aimerais vous soumettre un
scénario simplifié d'implémentation de verrous afin d'avoir votre avis.
Contexte :
La base de données contient 3 tables (T1, T2 et T3) dont le schéma est
organisé en « flocon ».
Trois clients requièrent des ressources, soit pour faire une mise à jour,
soit pour lire les données.
Quotidiennement et à heure fixe, une synchronisation est faite sur
l'ensemble des tables.
Voici des actions simultanées possibles :
Action #1 - Client #1:
Update T1 WITH (UPDLOCK)
Set champ1 = @ch1
From T1
Where T1.id = @id
Update T2 WITH (UPDLOCK)..idem
Update T3 WITH (UPDLOCK). idem
Action #2 - Client #2:
Update T1 WITH (UPDLOCK). idem
Update T2 WITH (UPDLOCK). idem
Update T3 WITH (UPDLOCK). idem
Action #3 - Client #3 :
Select * from T1, T2, T3 WITH (READPAST | NOLOCK)
Action #4 - Synchronisation automatique des nouvelles données :
Insert into T1 values ..
Insert into T2 values ..
Insert into T3 values ..
1-Serait-ce un scénario envisageable? Quelles pourraient être les
problèmes
d'un tel contexte?
2-Doit-on utiliser le type de verrou READPAST ou NOLOCK lors de la lecture
dans ce contexte?
3-Doit-on mettre un verrou lors des transactions d'insertion?
Merci à l'avance pour votre aide.
Merci beaucoup pour les informations et les liens. Toutefois, pourriez-vous
me préciser certains points que vous avez mentionnés, svp?
Les clients sont connectés en SQL. La MAJ est très simple et standard, sans
curseur, du genre:
Update T1
Set champ1 = @ch1
From T1
Where T1.id = @id
1 - Qu'entendez-vous par "client déconnecté"? Si les MAJ se font
successivement, alors il n'y a pas de problèmes de concurrence ?
2 - Si j'ai bien compris votre message, avec la façon décrite plus haut de
faire le Update,
a - SQL posera des verrous pessimistes, et le succès de la transaction
sera assuré
b - Il est préférable de ne pas "personnaliser" l'implémentation de
verrous dans la BD...
Merci de vos précisions.
"Fred BROUARD" a écrit :Tout dépend de la façons dont cette MAJ est faites.
Si c'est à travers un curseur (par exemple en client connecté tel que VB,
Delphi, C++, C#...) alors l'un des deux sera rejeté (verrous optimiste) avec un
message du genre : la version de la ligne considérée à changée, impossiblme de
mettre à jour.
Si client déconnecté alors les 2 maj se feront successivement.
Ne jamais utiliser directement les verrous, c'est comme cela que l'on tue une
base de données.
Lire sur les transactions en général :
http://sqlpro.developpez.com/cours/sqlaz/techniques/#L1
Sur les verrous SQL Server et les transactions SQL Server :
http://sqlpro.developpez.com/cours/sqlserver/transactsql/#L4.5
A +
--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************
carjo12 a écrit:Dans ce cas, qu'est-ce qui arrive si 2 personnes effectuent une mise à jour
en même temps, sur la même ligne?
Merci.
"Philippe T [MS]" a écrit :Bonjour,
Pourquoi ne pas simplement gérer des transactions et laisser SQL gérés ses
verrous ?
Lors d'un INSERT, pas besoin de verrous.
----------------------------------------------------------------------
Philippe TROTIN - Microsoft Service France
"carjo12" wrote in message
news:Bonjour
Je dois implémenter des verrous dans ma base de données. J'ai lu la
documentation SQL sur le sujet, et comme elle offre beaucoup de
possibilités
et qu'une telle action s'avère délicate, j'aimerais vous soumettre un
scénario simplifié d'implémentation de verrous afin d'avoir votre avis.
Contexte :
La base de données contient 3 tables (T1, T2 et T3) dont le schéma est
organisé en « flocon ».
Trois clients requièrent des ressources, soit pour faire une mise à jour,
soit pour lire les données.
Quotidiennement et à heure fixe, une synchronisation est faite sur
l'ensemble des tables.
Voici des actions simultanées possibles :
Action #1 - Client #1:
Update T1 WITH (UPDLOCK)
Set champ1 = @ch1From T1Where T1.id = @id
Update T2 WITH (UPDLOCK)..idem
Update T3 WITH (UPDLOCK). idem
Action #2 - Client #2:
Update T1 WITH (UPDLOCK). idem
Update T2 WITH (UPDLOCK). idem
Update T3 WITH (UPDLOCK). idem
Action #3 - Client #3 :
Select * from T1, T2, T3 WITH (READPAST | NOLOCK)
Action #4 - Synchronisation automatique des nouvelles données :
Insert into T1 values ..
Insert into T2 values ..
Insert into T3 values ..
1-Serait-ce un scénario envisageable? Quelles pourraient être les
problèmes
d'un tel contexte?
2-Doit-on utiliser le type de verrou READPAST ou NOLOCK lors de la lecture
dans ce contexte?
3-Doit-on mettre un verrou lors des transactions d'insertion?
Merci à l'avance pour votre aide.
Bonjour,
Comme d'habitude, entièrement d'accord avec Fred !!! :-)
Il est très rare d'être obligé de forcer des verrous alors que le moteur
sais si bien les gérer lui même !!! :-)
----------------------------------------------------------------------
Philippe TROTIN - Microsoft Service France
"Fred BROUARD" wrote in message
news:%
>
>
> carjo12 a écrit:
>> Merci beaucoup pour les informations et les liens. Toutefois,
>> pourriez-vous me préciser certains points que vous avez mentionnés, svp?
>>
>> Les clients sont connectés en SQL. La MAJ est très simple et standard,
>> sans curseur, du genre:
>>
>> Update T1
>> Set champ1 = @ch1
>> From T1
>> Where T1.id = @id
>>
>> 1 - Qu'entendez-vous par "client déconnecté"? Si les MAJ se font
>> successivement, alors il n'y a pas de problèmes de concurrence ?
>
> aucun
>
>>
>> 2 - Si j'ai bien compris votre message, avec la façon décrite plus haut
>> de faire le Update, a - SQL posera des verrous pessimistes, et le succès
>> de la transaction sera assuré
>> b - Il est préférable de ne pas "personnaliser" l'implémentation de
>> verrous dans la BD...
>
> Jamais de verouillage explicite
>
>>
>> Merci de vos précisions.
>>
>> "Fred BROUARD" a écrit :
>>
>>
>>>Tout dépend de la façons dont cette MAJ est faites.
>>>
>>>Si c'est à travers un curseur (par exemple en client connecté tel que VB,
>>>Delphi, C++, C#...) alors l'un des deux sera rejeté (verrous optimiste)
>>>avec un message du genre : la version de la ligne considérée à changée,
>>>impossiblme de mettre à jour.
>>>
>>>Si client déconnecté alors les 2 maj se feront successivement.
>>>
>>>Ne jamais utiliser directement les verrous, c'est comme cela que l'on tue
>>>une base de données.
>>>
>>>Lire sur les transactions en général :
>>>http://sqlpro.developpez.com/cours/sqlaz/techniques/#L1
>>>
>>>Sur les verrous SQL Server et les transactions SQL Server :
>>>http://sqlpro.developpez.com/cours/sqlserver/transactsql/#L4.5
>>>
>>>A +
>>>
>>>--
>>>Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
>>>Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
>>>Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
>>>************************ www.datasapiens.com *************************
>>>
>>>
>>>carjo12 a écrit:
>>>
>>>>Dans ce cas, qu'est-ce qui arrive si 2 personnes effectuent une mise à
>>>>jour en même temps, sur la même ligne?
>>>>
>>>>Merci.
>>>>
>>>>"Philippe T [MS]" a écrit :
>>>>
>>>>
>>>>
>>>>>Bonjour,
>>>>>
>>>>>Pourquoi ne pas simplement gérer des transactions et laisser SQL gérés
>>>>>ses verrous ?
>>>>>
>>>>>Lors d'un INSERT, pas besoin de verrous.
>>>>>
>>>>>----------------------------------------------------------------------
>>>>>Philippe TROTIN - Microsoft Service France
>>>>>
>>>>>"carjo12" wrote in message
>>>>>news:
>>>>>
>>>>>
>>>>>>Bonjour
>>>>>>
>>>>>>Je dois implémenter des verrous dans ma base de données. J'ai lu la
>>>>>>documentation SQL sur le sujet, et comme elle offre beaucoup de
>>>>>>possibilités
>>>>>>et qu'une telle action s'avère délicate, j'aimerais vous soumettre un
>>>>>>scénario simplifié d'implémentation de verrous afin d'avoir votre
>>>>>>avis.
>>>>>>
>>>>>>Contexte :
>>>>>>
>>>>>>La base de données contient 3 tables (T1, T2 et T3) dont le schéma est
>>>>>>organisé en « flocon ».
>>>>>>Trois clients requièrent des ressources, soit pour faire une mise à
>>>>>>jour,
>>>>>>soit pour lire les données.
>>>>>>Quotidiennement et à heure fixe, une synchronisation est faite sur
>>>>>>l'ensemble des tables.
>>>>>>
>>>>>>Voici des actions simultanées possibles :
>>>>>>
>>>>>>Action #1 - Client #1:
>>>>>>
>>>>>>Update T1 WITH (UPDLOCK)
>>>>>>Set champ1 = @ch1
>>>>>
>>>>>>From T1
>>>>>
>>>>>>Where T1.id = @id
>>>>>>
>>>>>>Update T2 WITH (UPDLOCK)..idem
>>>>>>Update T3 WITH (UPDLOCK). idem
>>>>>>
>>>>>>Action #2 - Client #2:
>>>>>>
>>>>>>Update T1 WITH (UPDLOCK). idem
>>>>>>Update T2 WITH (UPDLOCK). idem
>>>>>>Update T3 WITH (UPDLOCK). idem
>>>>>>
>>>>>>Action #3 - Client #3 :
>>>>>>
>>>>>>Select * from T1, T2, T3 WITH (READPAST | NOLOCK)
>>>>>>
>>>>>>Action #4 - Synchronisation automatique des nouvelles données :
>>>>>>
>>>>>>Insert into T1 values ..
>>>>>>Insert into T2 values ..
>>>>>>Insert into T3 values ..
>>>>>>
>>>>>>1-Serait-ce un scénario envisageable? Quelles pourraient être les
>>>>>>problèmes
>>>>>>d'un tel contexte?
>>>>>>
>>>>>>2-Doit-on utiliser le type de verrou READPAST ou NOLOCK lors de la
>>>>>>lecture
>>>>>>dans ce contexte?
>>>>>>
>>>>>>3-Doit-on mettre un verrou lors des transactions d'insertion?
>>>>>>
>>>>>>Merci à l'avance pour votre aide.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>
> --
> Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
> Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
> Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
> ************************ www.datasapiens.com *************************
>
Bonjour,
Comme d'habitude, entièrement d'accord avec Fred !!! :-)
Il est très rare d'être obligé de forcer des verrous alors que le moteur
sais si bien les gérer lui même !!! :-)
----------------------------------------------------------------------
Philippe TROTIN - Microsoft Service France
"Fred BROUARD" <brouardf@club-internet.fr> wrote in message
news:%23KGY6XNpFHA.3064@TK2MSFTNGP15.phx.gbl...
>
>
> carjo12 a écrit:
>> Merci beaucoup pour les informations et les liens. Toutefois,
>> pourriez-vous me préciser certains points que vous avez mentionnés, svp?
>>
>> Les clients sont connectés en SQL. La MAJ est très simple et standard,
>> sans curseur, du genre:
>>
>> Update T1
>> Set champ1 = @ch1
>> From T1
>> Where T1.id = @id
>>
>> 1 - Qu'entendez-vous par "client déconnecté"? Si les MAJ se font
>> successivement, alors il n'y a pas de problèmes de concurrence ?
>
> aucun
>
>>
>> 2 - Si j'ai bien compris votre message, avec la façon décrite plus haut
>> de faire le Update, a - SQL posera des verrous pessimistes, et le succès
>> de la transaction sera assuré
>> b - Il est préférable de ne pas "personnaliser" l'implémentation de
>> verrous dans la BD...
>
> Jamais de verouillage explicite
>
>>
>> Merci de vos précisions.
>>
>> "Fred BROUARD" a écrit :
>>
>>
>>>Tout dépend de la façons dont cette MAJ est faites.
>>>
>>>Si c'est à travers un curseur (par exemple en client connecté tel que VB,
>>>Delphi, C++, C#...) alors l'un des deux sera rejeté (verrous optimiste)
>>>avec un message du genre : la version de la ligne considérée à changée,
>>>impossiblme de mettre à jour.
>>>
>>>Si client déconnecté alors les 2 maj se feront successivement.
>>>
>>>Ne jamais utiliser directement les verrous, c'est comme cela que l'on tue
>>>une base de données.
>>>
>>>Lire sur les transactions en général :
>>>http://sqlpro.developpez.com/cours/sqlaz/techniques/#L1
>>>
>>>Sur les verrous SQL Server et les transactions SQL Server :
>>>http://sqlpro.developpez.com/cours/sqlserver/transactsql/#L4.5
>>>
>>>A +
>>>
>>>--
>>>Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
>>>Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
>>>Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
>>>************************ www.datasapiens.com *************************
>>>
>>>
>>>carjo12 a écrit:
>>>
>>>>Dans ce cas, qu'est-ce qui arrive si 2 personnes effectuent une mise à
>>>>jour en même temps, sur la même ligne?
>>>>
>>>>Merci.
>>>>
>>>>"Philippe T [MS]" a écrit :
>>>>
>>>>
>>>>
>>>>>Bonjour,
>>>>>
>>>>>Pourquoi ne pas simplement gérer des transactions et laisser SQL gérés
>>>>>ses verrous ?
>>>>>
>>>>>Lors d'un INSERT, pas besoin de verrous.
>>>>>
>>>>>----------------------------------------------------------------------
>>>>>Philippe TROTIN - Microsoft Service France
>>>>>
>>>>>"carjo12" <carjo12@discussions.microsoft.com> wrote in message
>>>>>news:97A1CFCB-7598-47B6-8317-CBBBEB686F77@microsoft.com...
>>>>>
>>>>>
>>>>>>Bonjour
>>>>>>
>>>>>>Je dois implémenter des verrous dans ma base de données. J'ai lu la
>>>>>>documentation SQL sur le sujet, et comme elle offre beaucoup de
>>>>>>possibilités
>>>>>>et qu'une telle action s'avère délicate, j'aimerais vous soumettre un
>>>>>>scénario simplifié d'implémentation de verrous afin d'avoir votre
>>>>>>avis.
>>>>>>
>>>>>>Contexte :
>>>>>>
>>>>>>La base de données contient 3 tables (T1, T2 et T3) dont le schéma est
>>>>>>organisé en « flocon ».
>>>>>>Trois clients requièrent des ressources, soit pour faire une mise à
>>>>>>jour,
>>>>>>soit pour lire les données.
>>>>>>Quotidiennement et à heure fixe, une synchronisation est faite sur
>>>>>>l'ensemble des tables.
>>>>>>
>>>>>>Voici des actions simultanées possibles :
>>>>>>
>>>>>>Action #1 - Client #1:
>>>>>>
>>>>>>Update T1 WITH (UPDLOCK)
>>>>>>Set champ1 = @ch1
>>>>>
>>>>>>From T1
>>>>>
>>>>>>Where T1.id = @id
>>>>>>
>>>>>>Update T2 WITH (UPDLOCK)..idem
>>>>>>Update T3 WITH (UPDLOCK). idem
>>>>>>
>>>>>>Action #2 - Client #2:
>>>>>>
>>>>>>Update T1 WITH (UPDLOCK). idem
>>>>>>Update T2 WITH (UPDLOCK). idem
>>>>>>Update T3 WITH (UPDLOCK). idem
>>>>>>
>>>>>>Action #3 - Client #3 :
>>>>>>
>>>>>>Select * from T1, T2, T3 WITH (READPAST | NOLOCK)
>>>>>>
>>>>>>Action #4 - Synchronisation automatique des nouvelles données :
>>>>>>
>>>>>>Insert into T1 values ..
>>>>>>Insert into T2 values ..
>>>>>>Insert into T3 values ..
>>>>>>
>>>>>>1-Serait-ce un scénario envisageable? Quelles pourraient être les
>>>>>>problèmes
>>>>>>d'un tel contexte?
>>>>>>
>>>>>>2-Doit-on utiliser le type de verrou READPAST ou NOLOCK lors de la
>>>>>>lecture
>>>>>>dans ce contexte?
>>>>>>
>>>>>>3-Doit-on mettre un verrou lors des transactions d'insertion?
>>>>>>
>>>>>>Merci à l'avance pour votre aide.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>
> --
> Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
> Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
> Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
> ************************ www.datasapiens.com *************************
>
Bonjour,
Comme d'habitude, entièrement d'accord avec Fred !!! :-)
Il est très rare d'être obligé de forcer des verrous alors que le moteur
sais si bien les gérer lui même !!! :-)
----------------------------------------------------------------------
Philippe TROTIN - Microsoft Service France
"Fred BROUARD" wrote in message
news:%
>
>
> carjo12 a écrit:
>> Merci beaucoup pour les informations et les liens. Toutefois,
>> pourriez-vous me préciser certains points que vous avez mentionnés, svp?
>>
>> Les clients sont connectés en SQL. La MAJ est très simple et standard,
>> sans curseur, du genre:
>>
>> Update T1
>> Set champ1 = @ch1
>> From T1
>> Where T1.id = @id
>>
>> 1 - Qu'entendez-vous par "client déconnecté"? Si les MAJ se font
>> successivement, alors il n'y a pas de problèmes de concurrence ?
>
> aucun
>
>>
>> 2 - Si j'ai bien compris votre message, avec la façon décrite plus haut
>> de faire le Update, a - SQL posera des verrous pessimistes, et le succès
>> de la transaction sera assuré
>> b - Il est préférable de ne pas "personnaliser" l'implémentation de
>> verrous dans la BD...
>
> Jamais de verouillage explicite
>
>>
>> Merci de vos précisions.
>>
>> "Fred BROUARD" a écrit :
>>
>>
>>>Tout dépend de la façons dont cette MAJ est faites.
>>>
>>>Si c'est à travers un curseur (par exemple en client connecté tel que VB,
>>>Delphi, C++, C#...) alors l'un des deux sera rejeté (verrous optimiste)
>>>avec un message du genre : la version de la ligne considérée à changée,
>>>impossiblme de mettre à jour.
>>>
>>>Si client déconnecté alors les 2 maj se feront successivement.
>>>
>>>Ne jamais utiliser directement les verrous, c'est comme cela que l'on tue
>>>une base de données.
>>>
>>>Lire sur les transactions en général :
>>>http://sqlpro.developpez.com/cours/sqlaz/techniques/#L1
>>>
>>>Sur les verrous SQL Server et les transactions SQL Server :
>>>http://sqlpro.developpez.com/cours/sqlserver/transactsql/#L4.5
>>>
>>>A +
>>>
>>>--
>>>Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
>>>Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
>>>Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
>>>************************ www.datasapiens.com *************************
>>>
>>>
>>>carjo12 a écrit:
>>>
>>>>Dans ce cas, qu'est-ce qui arrive si 2 personnes effectuent une mise à
>>>>jour en même temps, sur la même ligne?
>>>>
>>>>Merci.
>>>>
>>>>"Philippe T [MS]" a écrit :
>>>>
>>>>
>>>>
>>>>>Bonjour,
>>>>>
>>>>>Pourquoi ne pas simplement gérer des transactions et laisser SQL gérés
>>>>>ses verrous ?
>>>>>
>>>>>Lors d'un INSERT, pas besoin de verrous.
>>>>>
>>>>>----------------------------------------------------------------------
>>>>>Philippe TROTIN - Microsoft Service France
>>>>>
>>>>>"carjo12" wrote in message
>>>>>news:
>>>>>
>>>>>
>>>>>>Bonjour
>>>>>>
>>>>>>Je dois implémenter des verrous dans ma base de données. J'ai lu la
>>>>>>documentation SQL sur le sujet, et comme elle offre beaucoup de
>>>>>>possibilités
>>>>>>et qu'une telle action s'avère délicate, j'aimerais vous soumettre un
>>>>>>scénario simplifié d'implémentation de verrous afin d'avoir votre
>>>>>>avis.
>>>>>>
>>>>>>Contexte :
>>>>>>
>>>>>>La base de données contient 3 tables (T1, T2 et T3) dont le schéma est
>>>>>>organisé en « flocon ».
>>>>>>Trois clients requièrent des ressources, soit pour faire une mise à
>>>>>>jour,
>>>>>>soit pour lire les données.
>>>>>>Quotidiennement et à heure fixe, une synchronisation est faite sur
>>>>>>l'ensemble des tables.
>>>>>>
>>>>>>Voici des actions simultanées possibles :
>>>>>>
>>>>>>Action #1 - Client #1:
>>>>>>
>>>>>>Update T1 WITH (UPDLOCK)
>>>>>>Set champ1 = @ch1
>>>>>
>>>>>>From T1
>>>>>
>>>>>>Where T1.id = @id
>>>>>>
>>>>>>Update T2 WITH (UPDLOCK)..idem
>>>>>>Update T3 WITH (UPDLOCK). idem
>>>>>>
>>>>>>Action #2 - Client #2:
>>>>>>
>>>>>>Update T1 WITH (UPDLOCK). idem
>>>>>>Update T2 WITH (UPDLOCK). idem
>>>>>>Update T3 WITH (UPDLOCK). idem
>>>>>>
>>>>>>Action #3 - Client #3 :
>>>>>>
>>>>>>Select * from T1, T2, T3 WITH (READPAST | NOLOCK)
>>>>>>
>>>>>>Action #4 - Synchronisation automatique des nouvelles données :
>>>>>>
>>>>>>Insert into T1 values ..
>>>>>>Insert into T2 values ..
>>>>>>Insert into T3 values ..
>>>>>>
>>>>>>1-Serait-ce un scénario envisageable? Quelles pourraient être les
>>>>>>problèmes
>>>>>>d'un tel contexte?
>>>>>>
>>>>>>2-Doit-on utiliser le type de verrou READPAST ou NOLOCK lors de la
>>>>>>lecture
>>>>>>dans ce contexte?
>>>>>>
>>>>>>3-Doit-on mettre un verrou lors des transactions d'insertion?
>>>>>>
>>>>>>Merci à l'avance pour votre aide.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>
> --
> Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
> Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
> Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
> ************************ www.datasapiens.com *************************
>
