Discussion :

[kroma23]

delphi 7
interbase
j'ai développé une application qui tourne sous réseau,
L'application est installée sur 2 postes du réseau local.
Le problème, c'est que lorsqu'on modifie sur le poste 1 un enregistrement, le poste 2 ne le voit pas.
Pour que ça marche, il faut quitter l'application sur les postes 1 et 2 et relancer l'application sur le poste 2 pour qu'il ait pris en compte les modifications. pas pratique.
Est-ce que vous pouvez m'aider s.v.p pour que le poste 1 s'il modifie un enregistrement le poste 2 voit cette modification ?
Merci d'avance.

[SergioMaster]

Bonjour,

problèmes de transaction, manque de "refresh" ou alors tout simplement mauvaise compréhension de ce qui se passe ?

Pour que ça marche, il faut quitter l'application sur les postes 1 et 2 et relancer l'application sur le poste 2 pour qu'il ait pris en compte les modifications

et comment en arrivez vous à ce diagnostic via un affichage DBGrid ? (très mauvaise option)
Bref vous n'êtes pas assez clair

[ShaiLeTroll]

On dirait du BDE sans FlushBuffers côté écriture et sans Refresh (ou Close/Open) côté Lecture
Ou alors une mauvaise gestion des Transactions et du cache de mise à jour

On sait que c'est en Delphi 7 avec InterBase mais il nous manque une dernière information importante :
- Quel Provider ?

• BDE donc FlushBuffers ou ApplyUpdates
• IBX donc Transaction ou ApplyUpdates

Avec InterBase, proscrire l'utilisation du TTable ou TIBTable !
Et surtout ne pas faire les Open au début de programme et tous les Close à la fin !

Il faut tout écrire en TQuery ou TIBQuery
ne pas oublier de faire un Prepare des requêtes utilisées fréquemment,
avec BDE, fait un Prepare explicitement ou un Open (prepare implicite) ne change pas grand chose
avec IBX pour avoir des performances correctes, il faut impérativement faire un Prepare explicite car si l'on fait un Open (prepare implicite), le Close fera un unprepare implicite, ce qui nuit au performance (dix fois plus lent que le BDE alors qu'en explicite on peut être 10 fois plus rapide que le BDE, oui cela peut être un gain par 100 juste avec un mot de plus dans le code !)

Il faut ouvrir via Open l'objet requête, juste le temps nécessaire (généralement, le temps d'un traitement ou le temps de vie d'un écran) et le fermer dès qu'il n'est plus utile.
Il est préférables d'utiliser CachedUpdate pour valider un lot de données (généralement lors du clic sur un bouton Valider)
Pour IBX, prévenir des problèmes de cohérence des données sur plusieurs tables donc plusieurs ApplyUpdates avec une Transaction

Coupler le TQuery avec un TUpdateSQL si tu utilises Edit, Insert, Post ou Delete pour s'assurer que les SQL UPDATE, INSERT ou DELETE soit bien écrite, indispensable pour les modifications sur une jointure

Même principe TIBQuery couplé avec un TIBUpdateSQL

[kroma23]

merci pour vos réponses,
pour faire des insert ou update ou delete j'utilise des requettes de genre
with ibquery1 do
begin
close;
sqlclear;
sqladd('........................');
....................
.....................
open;
end;

est se que vous pouvez me donner un exemple pour faire Coupler le TIBQuery avec un TIBUpdateSQL car j"ai jamais essai se genre de programmation
merci d'avance.

[ShaiLeTroll]

Si tu fais directement tes modifications en SQL sans passer par Edit\Append\Post, tu n'a pas besoin du TIBUpdateSQL (voir plus bas quelque chose de similaire avec le TOraQuery)

Mais du coup, ton problème est très étrange car avec un INSERT\UPDATE en TIBQuery, tu devrais avoir les données en temps réel
Vérifie donc tes transactions et l'AutoCommit




Un exemple avec un TOraQuery qui est pour ORACLE qui fusionne le TIBQuery et TIBUpdateSQL en un seul objet
Désolé, je n'ai pas d'exemple simple, je ne l'utilise que TRES rarement parce que généralement je passe par une couche de persistance maison qui me génère les SQL automatiquement
Mais pour un écran de configuration, j'ai fait au plus vite en passant par le RAD

Voici le SELECT, cela affiche une matrice qui prend en compte deux critères sous la forme de thésaurus (table TP dictionnaire) et une table de décision pour chaque combinaison

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
SELECT mat.MAT_C_MAT, mat.MAT_CH_LIBELLE, pim.PIM_C_PIM, pim.PIM_CH_LIBELLE, rfmp.RQFD_N_DECISION
FROM TP_MAT mat
CROSS JOIN TP_PIM pim
LEFT JOIN T_DECISION_MAT_PIM rfmp ON rfmp.MAT_C_MAT = mat.MAT_C_MAT AND rfmp.PIM_C_PIM = pim.PIM_C_PIM
ORDER BY MAT_CH_LIBELLE, PIM_CH_LIBELLE

La requête est trop complexe pour déterminer ce qui doit être mis à jour !
Donc il faut lui fournir le SQL pour le ModifySQL

L'utilisateur à une grille lui permettant de choisir la décision approprié à un couple de critère
Il peut modifier la valeur (cela implique un DataSet.Edit et DataSet.Post)
Automatiquement lors du DataSet.Post sur un DataSet.Edit, cela invoque le SQL "ModifySQL"
Cela aurait invoqué InsertSQL sur un DataSet.Post d'un DataSet.Insert
et DeleteSQL sur un DataSet.Delete

Dans mon cas, on ne peut QUE modifier, le SELECT a été construit pour avoir toutes les combinaisons possibles dans la grille qu'il y ait une décision ou non.
Du coup, le ModifySQL gère la fois l'INSERT, l'UPDATE et le DELETE
Sur un SELECT plus simple, les trois aurait été bien séparé

Les valeurs modifiées sont passées sur forme de paramètre :NOM_DE_CHAMP
Dans la table de décision, je ne conserve que les valeurs utiles, lors de l'absence de décision cela retire le couple de la table

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
DECLARE
  AssociationExists NUMBER(1);
BEGIN
  SELECT COUNT(*) INTO AssociationExists
  FROM T_DECISION_MAT_PIM rfmp
  WHERE rfmp.MAT_C_MAT = :MAT_C_MAT
    AND rfmp.PIM_C_PIM = :PIM_C_PIM;
 
  IF AssociationExists = 1 THEN 
    IF :RQFD_N_DECISION IS NOT NULL AND :RQFD_N_DECISION > 0 THEN    
      UPDATE T_DECISION_MAT_PIM rfmp
      SET rfmp.RQFD_N_DECISION       = :RQFD_N_DECISION
      WHERE rfmp.MAT_C_MAT = :MAT_C_MAT
        AND rfmp.PIM_C_PIM = :PIM_C_PIM;
    ELSE
      DELETE FROM T_DECISION_MAT_PIM rfmp 
      WHERE rfmp.MAT_C_MAT = :MAT_C_MAT
        AND rfmp.PIM_C_PIM = :PIM_C_PIM;
    END IF;  
  ELSE 
    IF :RQFD_N_DECISION IS NOT NULL AND :RQFD_N_DECISION > 0 THEN    
      INSERT INTO T_DECISION_MAT_PIM (MAT_C_MAT, PIM_C_PIM, RQFD_N_DECISION) 
      VALUES (:MAT_C_MAT, :PIM_C_PIM, :RQFD_N_DECISION);
    END IF;
  END IF;
END;

[kroma23]

merci bien pour toute vos explications ,
est se que un close et open de la base de donnée après chaque mise a jour fait la faire ou non ?