Interbase et propagation de la modification temps réel

Bonsoir / Bonjour
je veux juste comprendre un concept ambigu pour moi après votre permission
moi j'ai pensé que par exemple un client ajoute un enregistrement à une table interbase l'autre client voire cette enregistrement en temps réel c'est à dire cette enregistrement est ajouter dans toutes les vus (dbgrid)des clients
moi j'ai fais un petit exemple qui fait l'ajout et la sélection dans une table IB puis j'ai lancer deux instances de la méme application pour voire est ce que l'ajout est temps réelé ou non mais c pas le cas quand j'ajoute un enregistrement dans une application il faut rafraichir l'autre application pour votre les nouveaux enregistrement ajoutés
est ce qu'il y a un composant spécifique qui fait la propagartion de la modification en temps réel
merci bien de votre aide.

Bonjour,

Citation:

---

Envoyé par hamza_java

moi j'ai pensé que par exemple un client ajoute un enregistrement à une table interbase l'autre client voire cette enregistrement en temps réel c'est à dire cette enregistrement est ajouté dans toutes les vues (dbgrid)des clients

---

Non, vos données étant "chargées" dans la grille sans action de votre part (ou plutôt de la part du programme : un refresh de la table) la grille des autres postes n'aura aucun changement. Sans entrer dans les détails c'est une question de transaction.
Considérez chaque poste comme une feuille de papier avec les enregistrements écrits dessus, si vous n'allez pas dans chaque bureau écrire sur chaque feuilles les modifications .

Comment y pallier ? pour cela il y a les évènements (Interbase comme Firebird, j'ai d'ailleurs publié une traduction à ce sujet il n'y a pas longtemps) que le programme devra surveiller pour que la mise à jour se fasse sur le poste. C'est pour cela que dans un environnement multi-utilisateurs on a tendance à ne pas utiliser de DBGrid ni de tables mais des requêtes de préférence sur un seul enregistrement ;)

Bonjour,

Oui c'est le comportement normal.

La plupart des applications sont comme ça. (Je ne parle pas de Dephi mais d'une manière générale)

Si vraiment vous voulez qu'une grille voient en 'temps réel' il faut faire des refresh régulier (toutes les secondes par exemple) (mais c'est lourd pour la base de données 100 clients connectés = 100 requêtes par secondes...)
ou mettre un système de message push qui lancerait uniquement le refresh des clients connectés sur la grille en question...

Le plus souvent le besoin de temps réel est totalement inutile.... Donc avant de vous embarquer dans ce genre de chose étudiez bien votre besoin....

Dans la même lancée, en général, le snaphost courant de l'utilisateur est suffisant

Pour la partie consultation :
C'est rarissime qu'il soit nécessaire de mettre en place un Refresh automatique mais tu as plusieurs possibilités

• les EVENT : TIBEvents
• Ton propre système de notification

Dans une problématique d'un accès centralisé à un produit tiers (un robot) via un server applicatif,
j'ai eu ce besoin de faire un refresh parce que le module devait afficher les modifications en temps-réel de ses propres actions émises via des requêtes asynchrones
Il n'y a d'ailleurs qu'un seul module qui le fait parce que le besoin est très particulier

J'ai mis en place un système de notification maison pour un projet
L'un des module "Client" se connecte à un "Server" et lui soumets des requêtes asynchrones et réagit au notification et à la réponse final, le toujours asynchrones
Le "Server" soumet lui même ses requêtes à un produit tiers ...
A chaque notification/réponse, ce module fait un Refresh d'un SQL, c'est la méthode choisie par le développeur, un peu lourde mais passons ...
Il aurait pu juste recharger la ligne concernée par la notification, surtout qu'il avait prévu un cache qui permettait cette optimisation

Lors d'une modification récente permettant de soumettre d'un seul coup un grand nombre de requêtes asynchrones, donc en retour un flot important de notification et de réponse
je me suis aperçu que le module saturait car il faisait plusieurs Refresh par seconde ( c'est monté à 40),
j'ai limité à 2 Refresh par seconde pour le confort et la réactivité nécessaire pour l'utilisateur,
si j'ai le temps, j'essayerais de faire un refresh restrictif

Le temps réel est très consommateur, il faut être prudent car beaucoup de client engendre potentiellement beaucoup de notification,
et faudrait pas qu'un module au final passe son temps à rafraichir inutilement les données par manque de granularité


Pour la partie mise à jour :
Pour prendre en compte, des modifications concurrentielles, tu as deux approches:

1. le dernier a toujours raison
2. conciliation

1. le dernier a toujours raison
   
   Dans ce cas, il est préférable de ne mettre à jour QUE les champs modifiés par l'utilisateur, il faudrait vérifier si ton provider (IBX, DBX, FB ...) gère cela
   
2. conciliation
   
   Typique en ADO, cela utilise tous les champs comme critère de mise à jour,
   si il ne trouve pas de correspondance c'est qu'il y a eu une mise à jour entre le chargement et la modification par un autre utilisateur,
   tu proposes à l'utilisateur si il préfère ses données ou celles venues entre temps