[AC-2007] Verrouillage et déverrouillage [Résolu]

[naphta]

Bonjour,

Ce problème a déjà été exposé sans doute.

Je dois verrouiller un formulaire avant enregistrement si cet enregistrement a été chargé sur un autre poste.

Comment faire pour verrouiller un seul enregistrement sachant que chaque enregistrement représente une quantité extrêmement faible de données quelques octets.

Lorsque l’on base le formulaire sur une requête access verrouille trop d’enregistrements et cela fausse le verrouillage.

J’ai l’idée de créer une table de verrous dans laquelle, au chargement du formulaire j’ajoute un enregistrement avec le champ contenant l'index de l'enregistrement à verrouiller, puis au déchargement j’efface ce dernier.

Est-ce une bonne idée ?
N’y-a-t-il pas mieux ?
a bientôt

[LedZeppII]

Bonjour,

Regarde Modifier le paramètre de verrouillage au niveau de la page ou de l'enregistrement.
Ça permet de choisir la granularité du verrouillage.
Ensuite, au niveau des requêtes et des formulaires, tu peux choisir entre verrouillage optimiste ou pessimiste («Aucun» ou «Enr modifié»).

A+

[naphta]

Merci du rappel Led Zepp2

J’ai l’impression de l’avoir déjà demandé et d’avoir déjà essayé, mais je vais recommencer.

Le client veut un verrou violent style interdiction stricte d'entrer dans les zones de saisies.

Bon WE

[micniv]

Bonjour,

J’ai l’idée de créer une table de verrous dans laquelle, au chargement du formulaire j’ajoute un enregistrement avec le champ contenant l'index de l'enregistrement à verrouiller, puis au déchargement j’efface ce dernier.
Est-ce une bonne idée ?

Après avoir essayé maints paramètrages sur les formulaires, je n'ai pas trouvé de verrouillage fiable intégré à Access Aussi je pense que OUI c'est une bonne solution de gérer une table des verrous dans laquelle tu mets les enregistrements verrouillés par qui et quand.
Bien cogiter aussi le déverrouillage : normalement l'utilisateur qui a verrouillé, déverrouille quand il quitte le formulaire mais il faut blinder l'appli en prévoyant des cas d'exceptions .

[naphta]

Bonsoir,

Bon ça marche avec la fameuse table de verrous !

Je ne voulais pas lier le formulaire à un requête ou une table par souci de performances. Donc pas de verrous, dernier arrivé dernier servi, pas bon.

Alors j'ai l'idée d'une table de verrous, on enregistre juste l'index de l'enregistrement ouvert dans cette table puis on le supprime après lecture/modification. On bloque le prochain utilisateur si l'index présent dans la table.

mais le souci c'est : que ce passe-t-il après un plantage ?

alors c'est une très mauvaise idée que j'abandonne.

a+

[micniv]

Non, Naphta, ce n'est pas une si mauvaise idée quand même !
Dans ma prochaine appli, il m'est demandé de maitriser le verrouillage et de pouvoir afficher le nom de l'utilisateur qui verrouille un enregistrement.
Pour ce, je compte :
. créer un maximum de formulaires indépendants(pour la performance et la disponibilité en réseau) (pas mal de code en perspective n'est-ce pas !)
. créer une table de verrouillage comme exposé par Naphta.
Pour gérer les plantages, je prévois 2 choses :
. chaque fois qu'un utilisateur se connecte à l'appli, tous les verrous associés à son nom donc (laissés depuis le précédent plantage éventuel) sont supprimés
. un utilisateur de profil ADMIN peut supprimer les verrous manuellement.

Maintenant à la pratique

[naphta]

Bonjour,

Merci micniv !

j'avais bien pensé à ajouter le user par son login avec "environ"
mais fallait que je rende l'appli vite ! et ça ramolli le cerveau.


ton idée de nettoyage est parfaite,
je dois faire de nouvelles modifs à ce client
je vais tester ton idée !

super merci

A bientôt