Discussion :

[vsavoir]

Bonjour,

Peut-on gérer les verrous d'un SGBD au niveau d'un réseau et non du propriétaire de la base de données.

Merci.

[Fabien Celaia]

Non, et je n'en vois pas l'utiliité. Les verrous sont géré par transaction et pas par utilisateur.

[vsavoir]

Et quand ça plante, tu fais comment pour supprimer les verrous qui n'ont pas pu être désactivés.

Merci.

[SQLpro]

C'est jusement le but des transactions :

COMMIT : valide les données et libère tous les verrous
ROLLBACK : défait toutes les modifs et libère les verrous.

Bien entendu si la transaction est commencée sur le poste client et que cela plante il y a coupure de la connexion et en principe ROLLBACK automatique, mais dans le time out imposé. Si ce time out est important, dommage !

C'est pourquoi il faut TOUJOURS gérer ses transacions côté serveur en les encapsulant dans des procédures stockées :
1) un OS serveur et les appli que l'on met dessus sont plus sécurisé que word ou excel ou flight simulator
2) un serveur est généralement une machine à tolérance de panne : alime redoandante, mémoire auto corrective, disque redondant extractibles à chaud...

A +

[vsavoir]

Merci bien pour vos réponses.

Je voulais savoir aussi concernant les verrous: la pose d'un verrou peut-elle concernée qu'un nombre d'enregistrement d'une table ou on a pas le choix, le verrou se pose sur la table entièrement?

Merci

[qi130]

ca dépend des possibilités du SGBD....

Parfois, on n'a pas le choix, ça ne peut être qu'au niveau de la table.

Cependant, la tendance est à l'"atomisation" des possibilités de lock, et nombre de SGBD proposent le verrou sur 1 ligne, parfois sur 1 ligne et sa suivante (MySQL).

[papounet]

De plus il existe une notion "ESCALE"
1 > => LOCK ROW
2 > => LOCK page à partir d'un certain nombre de LOCK ROW
3 > => LOCK table ensuite

[vsavoir]

Merci a tous pour vos réponses