Discussion :

[fffttt]

Bonjour

sur un nouveau projet (gestion commerciale avec commande achat, commande vente, BL, réception, facturation... pas de compta)

quelle serait selon vous la meilleure gestion des lock sachant que :
- développement partant de 0 (tout est donc permis)
- environ 50 utilisateurs (dont 10 en terminal serveur)
- on veut savoir qui bloque un enregistrement
=> si je veux faire une entrée en stock pour un article, savoir que machin est sur la fiche article en mode modif.
- si on modifie le stock d'un article, on aimerait alerter ceux qui sont sur la fiche article en mode consultation

en partant de 0 et avec ces "règles", vous feriez quelle méthode?

[Nicolas_Jeanneau]

Bonjour,

je me suis inspiré de l'exemple de WinDev sur la gestion des blocages. Au moins tu auras toutes tes attentes concernant les blocages. Il faudra juste ajouter les consultations donc tu auras besoin d'ajouter un champ pour le mode d'accès (modification ou consultation).

Bref tu as une table verrou avec la table concernée, l'id de l'enregistrement, le nom de la personne, la date de verrou, ... et tu ajoutes un flag pour modification.

Tu peux aussi envoyer des messages pour prévenir la personne que tu veux l'accès.

Bref, penches toi sur l'exemple pour voir le fonctionnement, c'est déjà un bon pas en avant.

à bientôt,

Nicolas

[fffttt]

bonjour

en effet on avait pensé à un truc du genre.
je vais regarder l'exemple dont tu parles.


mais que se passe t'il si l'utilisateur ne ferme pas correctement l'application? (ou si l'appli plante?)

[Nicolas_Jeanneau]

les entrées en bases de données restent et le verrou est maintenu.
Il te faut faire un traitement de suppression la nuit ou à un moment où personne n'est connecté pour vider la table en automatique.

Ensuite, tu as également une interface d'administration où tu peux faire sauter ces verrous à la demande.

[Nicolas_Jeanneau]

j'avais essayé de supprimer les verrous en ouverture de l'appli mais si l'utilisateur l'ouvre une 2e fois (si c'est possible), les verrous posés par la première ne sont plus actifs ...

[ErwanA]

j'avais essayé de supprimer les verrous en ouverture de l'appli mais si l'utilisateur l'ouvre une 2e fois (si c'est possible), les verrous posés par la première ne sont plus actifs ...

Dans ce cas, en rajoutant un test avec la fonction "ExeLancé", il devrait être possible d'éviter ce problème.

EDIT : Sauf peut-être pour le lancement en TSE.

[Nicolas_Jeanneau]

Sauf peut-être pour le lancement en TSE.

Ce qui est mon cas ... !

[DelphiManiac]

On peut tout à fait envisager de passer par une table de suivi pour tenir à jour ce que fait chaque instance de l'application.

Par contre cela ne permet pas d'informer automatiquement les autres instances qu'une nouvelle information est disponible dans la table de suivi, sauf à faire du pulling d'information sur la table, ce qui me paraît être une mauvaise idée. Pour pallier à ce problème et si l'on est en réseau local (pas de routage), on peut très bien envisager de faire du broadcast udp d'un signal indiquant toute modification de la table de suivi.

Concernant les locks de la table de suivi, il ne me semble pas intéressant de passer par les locks bdd, surtout que ce n'est pas une fonctionnalité disponible sur tout les serveurs de BDD. La solution que je préconiserais serait de passer par un dossier partagé sur un serveur et chaque instance qui se lance créée un fichier texte dans ce dossier et le lock. Si l'instance meurt le lock est enlevé par l'os, il suffit d'avoir un process qui tourne sur le serveur et épure la table de suivi des process mort.

Le tout me paraît un peu lourd, mais semble répondre à la demande.