Comment éviter les collusions avec sql server ?

Hello,

Je crois que tout est dans le titre.

Jusqu'ici je n'avais pas eu à me soucier de se problème car les applications qu'on m'avait demandé ne comportait pas de module d'édition de données mais ce n'est plus le cas.

Donc je vous le demande : Comment gérez-vous la collusion de données en .NET avec une DB de type SQL SERVER ?

J'ai bien pensé à ajouter un champ lock dans chaque table et mettre à jour (booléen ou username) ce champ quand un user accède au record pour l'éditer et le remettre à son état initial après mais ce n'est pas sûr à 100%.

Il s'agit de cas extrêmement rares mais si 2 utilisateurs choisissent le même record et cliquent sur le bouton d'édition avec un intervalle de temps inférieur au temps d'update du record, ils y accèderont tous les deux en mode édition.

Je suis p-e idéaliste mais je recherche donc une solution qui soit sûre à 100%.

Merci d'avance.

Griftou.

il y a plein de moyens de sécuriser ce gende de chose, mais il faudrait déjà que tu nous dises ce que tu veux empecher exactement (qu'un truc soit édité (et par éditer tu entends passer en mode modification ?) 2x en meme temps ou 2x tout court)
et aussi ce que tu veux faire quand un 2ème essaye d'éditer

NB : collision pas collusion (et en plus c'est pas vraiment une collision non plus, c'est éventuellement un accès concurrentiel)

En gros :

J'ai une fenêtre avec un datagridview qui reprend les records d'une table.
Toujours dans cette fenêtre, sous le datagridview se trouve un bouton d'édition.

Quand un utilisateur clique sur ce bouton, une fenêtre s'ouvre avec des champs saisies pour chaque champ du record dans lesquels se trouvent les valeurs de la DB.
Une fois la fenêtre ouverte, l'utilisateur modifie les données, clique sur le bouton OK et l'application met la DB à jour.

Ce que je veux éviter, c'est que quelqu'un puisse ouvrir cette fenêtre d'édition quand un autre user est déjà en train d'éditer le record en question.

Cela ne pose aucun problème si le délai entre les 2 demandes d'édition est suffisamment grand. Il suffit d'ajouter un champ "lock_by" (ou autre nom) de type varchar à la table et d'y écrire le nom de l'utilisateur qui est en train de l'éditer. Quand le second utilisateur arrive pour l'éditer, je vérifie d'abord si un username est écrit dans le champ et si oui, je l'informe que untel est déjà en train d'éditer ce record.

Par contre, si le délai entre les 2 demandes d'édition est inférieur au temps nécessaire à écrire le username du 1e utilisateur, lors de la vérification du champ pour autoriser l'édition au 2e utilisateur, le champ sera vide et l'accès lui sera autorisé.

Cela peut découler sur des problèmes d'intégrité ou de perte de données...

2 solutions en sql qui garantissent que ca ne pourra pas être ouvert sur 2 postes :
soit getapplock avec dans le nom du lock la clé de l'objet (préfixée d'un nom en dur)
tu demandes le lock, s'il passe tu fais ta requete normalement, s'il ne passe pas, quelqu'un est déjà sur cette ligne
soit un champ avec le username et au niveau du commandtext ca donne ca :

Code:

---

1 2	update table set lockchamp = 'username' where clé = valeurclé and lockchamp IS NULL select teschamps from table where clé = valeurclé and username = 'username'

---

la première requete fait que ca inscrit ton nom seulement s'il n'y a personne dessus
la 2ème fait le select seulement s'il y a ton nom dessus, si .read ne retourne aucune ligne, ca veut dire que tu n'as pas eut le verrou

avec cette 2ème méthode, il faut pouvoir être sûr de relacher le verrou
en théorie, remettre '' dans le champ lock à la fermeture de la fenetre, mais si ton appli plante à ce moment là, le verrou ne sera jamais relaché
la 1ère méthode permet elle de le relacher de manière totalement sûre, la fermeture de la connexion relachant le verrou


après il te reste le problème que si un user à modifié, il faudrait rafraichir ton datagrid sur l'autre poste

Je vais mettre en application la 2e méthode que tu donnes.

Un tout grand merci !!!

Par contre, pourrais-je avoir plus de détail concernant la première. Je ne suis pas certain de l'avoir bien comprise...:oops:

j'ai dit que la 2ème méthode était dangereuse ...

pour la première, si tu connais l'instruction synclock de vb.net ca y ressemble, mais au niveau de la base de données
c'est un peu comme une variable verrou, unique pour un nom as string
tu demandes le verrou avec par exemple "editmachin1528" 1528 étant la clé du machin à éditer
si quelqu'un a déjà appeler l'instruction spègetapplock avec la même chaine de caractère en paramètre, ca te répondre que le verrou est déjà pris
si personne ne l'a ca va te donner le verrou

tu laisses la connexion ouverte jusqu'à la fermeture de la fenêtre et rien de plus à faire (ouvrir la connexion et demander le verrou avant d'ouvrir la fenêtre)
et là au moins si l'appli plante, la connexion sera fermée quand même et le verrou sera relachée
alors qu'avec l'autre méthode, il faudrait aller grater dans la base pour retirer le verrou ou mettre en place des mécanismes douteux

Je vais voir ce que je trouve sur cette instruction applock.

Je ne connais pas du tout.

Je suis bien conscient des désavantages de l'autre méthode. Mais il s'agit d'une application assez simple au demeurant. Peu de risque de plantage. Et la gestion des erreurs n'est pas très fastidieuse. Pour le moment, je vais faire comme ça, quitte à changer de méthode plus tard.

A savoir que lors de la mise en place du deuxième système tu peux directement prévoire soit:

Un batch automatique, un bouton magique dans une interface admi qui débloque ces verrous ou prévoir une task force en hotline (l'un n'empeche pas l'autre).

Car à chaque plantage de l'application faudra dévérouiller à la main (On aimerait tous que nos applications se plante jamais, mais voila...)

A savoir qu'il existe 3 "écoles" pour gérer la problèmatique de l'édition à plusieurs en même temps qui sont plus ou moins adaptées en fonction de la situation.

Je te conseille donc de faire quelque recherche sur les "accès concurrentiel" au base de donnée et d'adopter une méthode qui correspond réellement à tes besoins avec une gestion efficiante (efficace + moindre cout).