SQL Server Evenement sur Delphi

Bonjour tout le monde,
Je Travail sur une Application qui fonctionne sous réseau avec plusieurs postes le but est que à chaque insertion ou bien modification via n'importe quel poste le résultat s'affiche de manière automatique sur le reste des poste, pour cela j'ai fouiner sur le net pour le cas de INTERBASE et FIREBIRD l'instruction POST_EVENT dans un TRIGGER fait l'affaire mais ce n'est pas le cas sur SQL SERVER, J'ai trouvé une piste qui propose le SERVICE BROKER de SQL SERVER mais j'ai rien trouver comment l'implémenter sur DELPHI.
Question : comment avoir les données de manière instantané sur tout les poste après chaque modification.
Remarque : Je développe sur Embarcadero Tokyo 10.2.3 avec SQL SERVER 2014

Bonjour,

SQL Server n'est pas Interbase ou Firebird suivre la piste des IBevents ou FBevents ne peut être envisagée.
La première chose à faire est de comprendre comment le Service Broker de MS SQL Server fonctionne et ensuite de voir s'il est possible d'interroger ces SERVICES sans parler d'autres termes comme CONTRACT et ROUTE

enfin mes recherches (rapides) sur cette question m'indique que c'est possible
:google: avec les mots clés "Delphi SQL server Service broker"

Citation:

---

Yes, is possible use delphi to access to the notifications and Events exposed by the MSSQL Service Broker. To do this you can use the WMI Provider for Server Events which exposes a very rich set of WMi events and classes. If you are new to the WMI, I recommend you which read these articles Accesing the WMI from Object Pascal Code and Delphi and WMI Events also you can use the WMI Delphi Code Creator to create an Delphi snippet to access the events of the MSSQL Service Broker.

---

Certes WMI ce n'est pas facile (même avec WMI Delphi Code Creator) il va falloir trouver les bons chemins !

Lire mise à jour en temps réel dbgrid où j'évoque le SDAC TMSServiceBroker

D'ailleurs SQL Server, est attaqué via quel provider ?
ADO ? OLE.DB ? FireDac ? UniDac ? SDAC ... il y en a tellement

J'ai vu cela employé pour ORACLE, cela provoque une consommation réseau importante car souvent la notification provoque une lecture par les destinataires, si tout le monde affiche les mêmes données au même moment, cela peut arriver lors de campagne événementiel d'une société, comme les inventaires, les bilans et clôtures, référencements produits ...

Pourquoi ne pas avoir un MiddleWare typique d'une architecture N-Tiers ?
Le client utilise le MiddleWare pour mettre à jour la base de données, celui-ci notifie les clients abonnés, gèrent un cache de données au passage
Ainsi ce n'est pas la base de données qui sert de notification mais le logiciel métier.
Les clients notifiés n'ont pas besoin de relancer des SQL puisque le MiddleWare fourni les modifications.

Tu peux aussi faire un refresh SQL mais à la demande de l'utilisateur via un système de feu tricolore.
L'utilisateur A ouvre la Fiche Bidule ID 1, le feu est vert
L'utilisateur B ouvre la Fiche Bidule ID 1, le feu est vert
L'utilisateur C ouvre la Fiche Bidule ID 1, le feu est vert
L'utilisateur A commence la modification de la Fiche Bidule ID 1, le feu passe à l'orange chez B et chez C
L'utilisateur B et C ne peuvent pas modifier la Fiche Bidule ID 1 (un LOCK strict mais l'on peut aussi prévoir un LOCK plus ouvert et une Conciliation pour la fusion de donnée de plusieurs modifications concurrentes)
L'utilisateur A valide la modification de la Fiche Bidule ID 1, le feu passe au rouge chez B et chez C
L'utilisateur B et C doivent rafraichir la Fiche Bidule ID 1 avant de poursuivre une éventuelle modification (certains utilisateurs préféraient une mise à jour manuelle qu'automatique pouvant être perturbante de voir les données changer en cours de lecture)

Tout ça ce n'est qu'au niveau Fiche donc assez limité
Si tu veux envisager un Refresh de Grille lorsqu'une Fiche est modifié, tu imagines que si tu as beaucoup d'utilisateur, tous qui affichent des grilles, peut-être plusieurs et qu'il y a en parallèle de nombreuses modifications.
As-tu penser aux imports de données par exemple, quand des milliers de Ficher sont mises à jour, tu ne penses pas notifier tous les clients ouverts de cela via des TRIGGER\EVENT ?

Sinon, où je travaille, nous avons le MiddleWare ... et son nom c'est le Broker ... et oui il existe depuis 15 ans, on n'invente rien, le Broker maison est inspiré du Broker MS SQL.
Important ce MiddleWare car le logiciel fonctionnait avec ORACLE et SQL Server selon le choix d'architecture du client, aujourd'hui il ne reste que SQL Server mais la structure N-Tiers n'a pas changé.


J'avancerais donc avec prudence sur ce sujet, une bonne étude de la volumétrie, des accès concurrentiels ainsi que la compréhension par l'utilisateur de ce système.