Discussion :

[GrPtj]

Bonjour,
Dans un travail client/serveur, une question se pose souvent au moment de valider des modifications :
savoir si la table du serveur a été modifiée depuis sa lecture par le client.
J'ai lu que l'on peut utiliser le paramètre TxOption.isolation du connecteur firedac.
ou le paramètre ResourceOptions.CmdExecMode de la requète.
Je crois qu'il y a aussi des verrous dans la table ?
Quelle est la meilleure méthode pour charger des données, ne pas bloquer les données pour un autre utilisateur
et savoir au retour si une ligne d'une table est modifiée depuis le chargement ?

[GrPtj]

peut-être y a-t-il dans firebird une gestion des lignes modifiées ?

[GrPtj]

J'ai essayé avec la fonction refresh mais cela ne me convient pas ...
Le rafraichissement ne se fait que si rien n'a été modifié ?

ouvre FDQuery1 sur Tb1
ouvre FDquery2 sur Tb1, modif valeur d'un champ d'une ligne, commit

1/ refresh + Modif1 OK
FDQuery1.refresh > prend les valeurs envoyées par FDQuery2
modif d'un autre champ sur Tb1
commit -> Tb1 contient les deux modifications successives, la dernière si c'est le même champ qui a été modifié

2/ Modi1 + refresh
modif d'un autre champ sur Tb1
FDQuery1.refresh > ne prend pas les valeurs envoyées par FDQuery2
commit -> Tb1 contient Modif1 mais ne contient pas modif2

Ce que je voudrais au minimum dans le cas 2/ c'est un message indiquant que je n'ai pas la dernière version.

[SergioMaster]

Bonjour,

Tout d'abord, à la lumière de vos autres posts pratiquement sur le même sujet j'ai l'impression d'une usine à gaz et d'une maitrise imparfaite des transactions et Firebird.
Le dernier post étant tout sauf clair je ne vais pas y répondre et sans vraiment répondre à la demande de départ je vais quand même indiqué quelques pistes n'utilisant que Firebird.

savoir si la table du serveur a été modifiée depuis sa lecture par le client.

Table est-ce le bon terme ?
s'il s'agit d'une ligne de la table, l'utilisation des triggers AfterInsert,AfterPost et une colonne timestamp devrait certainement être suffisant.

Sinon il y a aussi les EVENTS il y déjà quelques années j'ai traduit un article intéressant à ce sujet http://serge-girard.developpez.com/a...rebird-events/

Je crois qu'il y a aussi des verrous dans la table ?

oui, ce qu'un simple petit tour dans la doc permet de confirmer https://firebirdsql.org/refdocs/lang...-withlock.html

Quelle est la meilleure méthode pour charger des données, ne pas bloquer les données pour un autre utilisateur
et savoir au retour si une ligne d'une table est modifiée depuis le chargement ?

je ne pense pas qu'il y ait de "meilleure méthode" tout dépend du contexte. Côté Delphi, le plus souvent je ne travaille pas sur des tables mais en interrogation sur des requêtes et en saisie sur une requête d'un singleton (une ligne de la table) donc facile à verrouiller. Dans de très rares (i.e. campagne de phoning) cas j'ai utilisé les events

[Paul TOTH]

si j'ai bien compris la question c'est de savoir si avant de poster les modifications d'un enregistrement, ledit enregistrement n'a pas été modifié par quelqu'un d'autre dans la base.

les idées sont généralement les suivantes

1) verrouiller l'enregistrement à l'ouverture...je n'aime pas cela car si le type part en pause café, ça peut prendre un temps certain

2) relire l'enregistrement avant de le poster pour contrôler s'il a été modifié (je pense que c'est rarement fait en pratique)

3) c'est le dernier qui dit qui a raison...c'est à dire qu'on écrase la modification qui a eut lieu entre deux

dans un de mes projets FIREBIRD un prédécesseur avait mis au point une méthode un peu alambiquée mais qui fonctionne plus ou moins

au lieu de verrouiller l'enregistrement, un EVENT Firebird est lancé sur le OnChange d'un champ d'édition exemple "LOCK_NOM_CLIENT#123" pour dire que le nom du client n° 123 a été modifié
du coup tous les postes qui sont sur l'enregistrement 123 désactive le champ d'édition du Nom afin d'en interdire la modification.
une fois l'enregistrement posté sur le premier poste, il balance un event "UNLOCK_NOM_CLIENT#123" qui a pour effet de déverrouiller les champs de saisie des autres postes et de les mettre à jour !

et donc tous les postes sont à l'écoute de tous les évènements LOCK/UNLOCK de tous les champs de l'enregistrement 123...car il n'y a pas de paramètre dans les EVENT FB...c'est un peu lourd mais ça fonctionne à peu près car le fait d'ouvrir l'enregistrement ne le verrouille pas, c'est uniquement quand on passe en modification...

la seule subtilité ensuite c'est qu'à l'ouverture de l'enregistrement 123 on lance l'event "QUERY_CLIENT#123" (autre event à suvire) pour savoir si quelqu'un est en édition, et récupérer les "LOCKxxx" en cours.

[GrPtj]

Merci pour vos réponses.

maitrise imparfaite des transactions et Firebird

c'est le cas !!

la question c'est de savoir si avant de poster les modifications d'un enregistrement, ledit enregistrement n'a pas été modifié par quelqu'un d'autre dans la base

Exactement !

2) relire l'enregistrement avant de le poster pour contrôler s'il a été modifié (je pense que c'est rarement fait en pratique)

C'est la méthode que j'utilise actuellement mais c'est assez lourd ...

3) c'est le dernier qui dit qui a raison...

C'est ce que je voudrais éviter !

l'utilisation des triggers AfterInsert,AfterPost et une colonne timestamp devrait certainement être suffisant

Je vais reprendre de ce coté là.
Je voulais être sûre qu'il n'existait pas une solution qui m'aurait échappée !