Discussion :

[yellowsub122]

Bonsoir.

Je suis un vrai débutant.
J'essaye de faire pour le fun une application ASP.Net (VB.Net) qui met à jour des données dans une base.
En gros, j'ai une base et un formulaire. A travers ce formulaire, je mets à jour une table.

Ma question est la suivante: les applications "web" étant des applications en mode "déconnecté", comment m'assurer que l'enregistrement sur lequel un utilisateur travaille ne soit pas accessible par un autre utilisateur ?

Je voudrais éviter que 2 utilisateurs puissent accéder au même enregistrement pour mettre à jour !

Merci pour votre aide.

[Graffito]

Il y a le choix entre solution "optimiste" et solution "pessimiste".

• La solution pessimiste consiste à mettre un verrou sur l'enregistrement dès qu'on veut entrer en edition. Inconvénients : si l'édition est stoppée, l'enregstriment ne se dévérouillera qu'au bout d'un time-out, et il faut vérifier lors de la mise à jour que le verrou est toujours en place.
• La solution optimiste consiste à s'assurer lors de la mise à jour que l'enregistrement modifié correspond à celui qui a été lu avant édition.

[yellowsub122]

Il y a le choix entre solution "optimiste" et solution "pessimiste".

• La solution pessimiste consiste à mettre un verrou sur l'enregistrement dès qu'on veut entrer en edition. Inconvénients : si l'édition est stoppée, l'enregstriment ne se dévérouillera qu'au bout d'un time-out, et il faut vérifier lors de la mise à jour que le verrou est toujours en place.
• La solution optimiste consiste à s'assurer lors de la mise à jour que l'enregistrement modifié correspond à celui qui a été lu avant édition.

Bonjour.

je me suis levé du bon pied ce matin aussi vais-je essayer de partir sur la solution optimiste.
Si j'ai bien compris, il "suffirait" de s'assurer de mettre un critère dans la requête "update" soit unique n'est-ce pas ? (update table_toto set colonne_titi='...' where critère unique).

Merci.

[cybermaxs]

Bonjour.

je me suis levé du bon pied ce matin aussi vais-je essayer de partir sur la solution optimiste.
Si j'ai bien compris, il "suffirait" de s'assurer de mettre un critère dans la requête "update" soit unique n'est-ce pas ? (update table_toto set colonne_titi='...' where critère unique).

Merci.

Oui. Dans la pratique, on ajoute aussi souvent une colonne dédiée de type timestamp ou autre. Lors du chargement de ligne ou de l'objet, tu récupère cette valeur avec le reste. Lors de l'update tu ajoutes une condition dans le where pour mettre à jour que si le timestamp est égal. (ne pas oublier de la mettre à jour aussi). Ensuite en analysant le nombre de requêtes affectées, tu peux dire si tes données étaient à jour ou pas.

[Graffito]

il "suffirait" de s'assurer de mettre un critère dans la requête "update" soit unique n'est-ce pas ? (update table_toto set colonne_titi='...' where critère unique).

Perso, je vérifie l'égalité de tous les champs lus.
Sinon, lors des update, on peut toujours utiliser une transaction pour mettre dans l'enregistrement un ticket unique chaque fois qu'on écrit dedans. Il suffit alors de tester que la valeur du ticket n'a pas changé.

[cybermaxs]

Perso, je vérifie l'égalité de tous les champs lus.
Sinon, lors des update, on peut toujours utiliser une transaction pour mettre dans l'enregistrement un ticket unique chaque fois qu'on écrit dedans. Il suffit alors de tester que la valeur du ticket n'a pas changé.

d'où l'idée du timestamp ... Car pour tes tables avec 20 colonnes, ça devient barbant à faire.