Exception "Enregistrement verrouillé"

[sniperpro]

Bonjour,

J'en ai deux application, qui opèrent sur la même table paradox, le problème est que lorsque un enregistrement de la table entre en mode édition, par la première application, il ne peut pas être éditer par la deuxième :

Enregistrement verrouillé par un autre utilisateur

Une idée pour contourner ce problème et ne pas bloquer l'application.?

[al1_24]

Suppose que chaque application modifie la même colonne de cet enregistrement de manière différente... Quelle version es-tu sensé conserver ?

[sniperpro]

Bonjour al1_24,

Bon ce cas de figure ne se produira jamais, car les deux applications sont des pointeuses donc un enregistrement n'est affecté que lorsque le personnel pointe.

Même le cas ou deux pointeuses affecte le même enregistrement en même temps ne se produit pas, car le personnel ne peut pas pointer au même temps à deux pointeuses différentes.

Mais comme même je dois gérer l'exception, rien n'est garantie.

[comico]

Bonsoir

Paradox utilise un mode de verrouillage préventif (lock pessimiste) qui explique ce que vous constatez. Le moyen classique de contourner cela (pour une grosse application avec beaucoup de concurrence d'accès) est de se rapprocher d'un fonctionnement client-serveur.

Les écrans de saisie prennent une copie de l'enregistrement de la table serveur dans une table locale (répertoire privé par exemple).

L'utilisateur effectue ses modifications en local puis un bouton <Valider> s'occupe de mettre à jour l'enregistrement sur le serveur par un TCursor. Dans ce fonctionnement les accès en écriture son très limités et la concurrence ne devrait plus poser de souci.

Il faut éventuellement se soucier de vérifier que l'enregistrement que l'on s'apprête à modifier n'a pas déjà été modifié entre temps par un autre utilisateur, ce qui peut se faire de différentes façon, la plus simple étant sans doute de gérer un champ "DateTimeModif" (certains préfèrent un champ N°version d'enregistrement).

Parfois ce point ne pose pas de souci et on accepte que "le dernier qui parle écrase les versions précédentes". Tout dépend du besoin métier et du type d'application.

Le passage en client-serveur, également possible depuis Paradox, n'est pas la solution miracle non plus. On a exactement les même problèmes de concurrences mais avec un mode de gestion supplémentaire via les transactions.

[comico]

Mais le souci décrit pour une application de pointeuse si j'ai bien suivi, est un peu étonnant.

Comment se fait-t-il que les 2 applications cherchent à écrire le même enregistrement en même temps ?

Il y a potentiellement un problème de conception et de modélisation de la base de données.

[comico]

En relisant votre réponse à al1_24 j'ai un doute sur le souci réel.

Il y a une particularité dans les fiches multi-tables paradox qui pourrait expliquer votre souci :

Si dans une fiche, dans votre modèle ralationnel vous joignez 2 tables avec mettons une relation 1->N , un enregistrement maître a n enregistremernts détails, dans ce cas paradox va locker en écriture l'enregistrement maitre dès que vous modifiez un enregistrement détail... Ce comportement est automatique et peut se comprendre (souhait de mettre à jour des cumuls par exemple dans la table maitre). Le problème c'est que l'on ne peut pas désactiver ce comportement.

La solution dans ce cas est de briser le lien dans le modèle relationnel et de gérer le filtrage des enregistrements détails par programmation lors d'un newvalue de la clé de l'enregistrement maître (via un SetRange c'est instantanné, c'est ce qu'utilise Paradox en fait en interne)

Bon j'essaie là de deviner votre souci pas sûr que j'ai bien tout compris !