Discussion :

[J0r_x]

Bonjour,

Une petite question au niveau des transactions.
Dans une application Windev, lors de l'ouverture d'une fenêtre en modification de données, je lance une transaction et je bloque l'enregistrement WITH (UPDLOCK,ROWLOCK).
Mes autres enregistrements sont disponibles en lecture et en modification, et l'enregistrement modifié peut être lue mais pas modifié.
Lorsque j'effectue la mise à jour de cette enregistrement (UPDATE) tant que je n'effectue pas le COMMIT TRANSACTION je ne peux pas accéder à celui-ci en modification mais aussi en lecture.
Pourquoi j'arrive à le lire avant la mise à jour mais pas après ?

[mikedavem]

Bonjour,

UPDLOCK représente un verrou de type U qui est une intention de poser un verrou exclusif pour la mise à jour des données. Ce type de verrouillage prémuni les données contre les autres tentatives de verrous de même type ou exclusif.

Cependant lorsque vous mettez à jour vos données, ce verrou se transforme en verrou exclusif (X). Ce type de verrou empêche l'accès aux données concernées (sauf si vous effectuez des lectures sales avec le mode d'isolation READUNCOMMITED ou avec un hint nolock).

Si vous ne validez pas votre transaction ce verrou est maintenu. C'est la raison pour laquelle vous ne pouvez plus accéder à vos données à ce moment.

++

[J0r_x]

On ne peux pas effectuer une mise à jour et rester en verrou de type U ?

[mikedavem]

Non et heureusement ....

Si une telle chose était permis il serait impossible de respecter les propriétés ACID d'une transaction.

++

[J0r_x]

Donc je n'ai aucune possibilité de lecture de cette enregistrement tant qu'il n'est pas "COMMIT" ?

[mikedavem]

Si vous pouvez utiliser le mode d'isolation qui permet les lectures impropes ou sales ... ou le HINT nolock

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
-- Niveau d'isolation READ UNCOMMITED
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
 
SELECT * FROM maTable;

ou

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
-- Query hint
SELECT * FROM maTable (nolock)

Cependant faites attention avec cela car vous allez au devant de problèmes de cohérence de données si vous ne maitrisez pas ce que vous faites

++

[elsuket]

Ou tout simplement ne pas utiliser d'indicateur de requête.

SQL Server gère les modifications de données tout seul comme un grand, et il est plus au courant que vous (si si) de la meilleure stratégie de verrouillage à utiliser.

Une autre possibilité est d'utiliser le niveau d'isolation de transaction REPEATABLE READ ou SERIALIZABLE ... mais bannissez ces indicateurs de requête !

@++