Conflit d'écriture et verrouillage par page

Bonjour à tous,

Comme le titre l'indique : problème de conflit d'écriture/verrouillage :
j'ai une base access splitée en dorsale/frontale, et autant d'utilisateurs que de frontales.

Le problème se situe dans le mode de verrouillage d'un formulaire dans lequel on navigue antre les enregistrements avec les boutons.
J'ai mis le verrouillage en mode "enregistrement modifié", pensant que cela permettrait de contrôler que deux utilisateurs ne modifient pas en même temps un enregistrement > ça marche, mais je constate qu'en faisant ainsi, Access verrouille également toute une page d'enregistrements (14) :calim2:
et pas seulement celui qui est déjà en écriture.
Je précise que le formulaire est basé sur une requête.

Avez vous eu le cas? :weird:

merci par avance...

Bonjour.

Hélas, Access ment quand il dit qu'il bloque l'enregistrement.
En interne, il verrouille un bloc de 2000 octets donc il peut bloquer plusieurs enregistrements d'un seul coup.
Autant que je sache, il n'y a pas de contournement possible.
La seule échappatoire est de supprimer la gestion du verrouillage ... ce qui n'est vraiment pas recommandé.
Tu peux peut-être repenser ton mode de saisie ou ton organisation de saisie pour éviter que les utilisateurs "se marche sur les pieds."

A+

Merci Marot_r

C'est bien ce que je craignais... Il va donc falloir que je repense toute la circulation dans le soft. :aie:

Je me demande comment j'ai pu échapper à ce bug depuis tout ce temps...

Y a t'il un moyen de tester si un autre utilisateur est déjà entrain d'écrire sur un enregistrement? J'ai essayé avec la propriété dirty, mais cela ne répond pas. Comment savoir si un enregistrement est en écriture?

J'ai cherché dans le forum, mais je n'ai pas trouvé de tuto : comment gérez vous (globalement) les modifications des enregistrements en multi utilisateurs? Je ne vois même pas comment aborder le problème, les utilisateurs travaillant tous dans les mêmes tables!
Il faudrait enlever le verrouillage, et tester si quelqu'un est déjà sur un enregistrement...

Merci...

Bonjour.

Citation:

---

Je me demande comment j'ai pu échapper à ce bug depuis tout ce temps...

---

La chance.

Citation:

---

Il faudrait enlever le verrouillage, et tester si quelqu'un est déjà sur un enregistrement...

---

Tu peux essayer en changeant le type de verrouillage (c'est dans les options générales de l'appli et peut-être aussi plus localisé au niveau du form) et en implantant toi-même un mécanisme de sémaphore qui permet l'accès exclusif.

Ici un article sur le sujet.
Sémaphore (informatique)
https://fr.wikipedia.org/wiki/S%C3%A...(informatique)
Le sémaphore pourrait être un fichier texte commun ou une table que tu ouvres en accès exclusif le temps de manipuler le sémaphore.
Dans l'ensemble le processus est bon mais il faut prévoir le cas où le propriétaire du sémaphore ne le rend pas (plantage de l'appli avant la fin du cycle).
Le déclenchement du sémaphore pourrait être sur l'événement change du contrôle de saisie.
Si il se déclenche c'est que l'utilisateur modifie l'enregistrement.

Si tu ne fais rien c'est le principe du dernier qui a validé sa saisie a raison ... cela peut être jouable.

A+

Merci Marot_r

La lecture de l'article sur le Sémaphore m'a effrayée dès son premier tiers :aie:
mais je vais persévérer!

Je tente pour le moment de supprimer le verrouillage du form, et de laisser la main au dernier qui a validé. J'avais des .recalc sur certains évènements de formulaires, qui généraient des erreurs majeures si deux utilisateurs étaient en même temps sur un même enregistrement. >>enregistrement totalement vérolé, avec des hiéroglyphes... En les remplaçant par de simples refresh ça passe mieux.

Y a t'il un moyen, sur un formulaire continu, de savoir si quelqu'un modifie déjà l'enregistrement dans lequel vous entrez?

je vais me replonger ans ton article...

Bonjour.

Citation:

---

La lecture de l'article sur le Sémaphore m'a effrayée dès son premier tiers

---

Oui, moi aussi la première fois que je l'ai étudié.
L'important est de disposer d'un enchaînement d'événements qui ne peut pas être interrompu entre le moment où tu requières le sémaphore et celui ou tu le manipules.
D'où l'idée de la table en mode exclusive ou le fichier.

A+

Je vais regarder ça de plus près, certainement en mettant en place différents formulaires, saisie, modification, consultation, qui servent juste d'interface (sur table temporaire?) pour mette à jour la table, sans travailler directement dedans.

et je vais aussi étudier le sémaphore et voir comment adapter ceci...
Bref, je vais devoir revoir mon flux d'infos...

merci!

Avant de tout modifier, Est-ce que 2 personnes ou plus sont censées modifier le même enregistrement ?

Si non, tu peux peut-être supprimer la gestion des verrous sur cet écran en particulier.

A+