Ohne die spezielle Anwendungslogik zu kennen, gleicht eine Ferndiagnose Hellseherei...und das ist ganz nah an Scharlatanerie.
Egal, hier meine Empfehlung: Firebird-Events erfordern eine aktive Connection zur Datenbank; Du müsstest Deine Clients ggf. gleichzeitig zu allen 3
DB's verbinden. Warum also nicht gleich alles in eine
DB packen?
Dass
FB seine Clients per Events "informiert", dass etwas passiert ist, gehört zu den eher coolen Features: Push-Notification hat z.B. Blackberries zu Managers Liebling gemacht. Das klassische Polling (per Timer die Clients nötigen, auf Änderungen zu checken) ist eher Bäh im C/S-Umfeld.
Aber natürlich steht es Dir frei, die Event-Notification vom
DB-Server in die Clients zu verlagern: Auch dort kannst Du z.B. per UDP-Broadcasting Deinen Client in's Netz brüllen lassen und die Client-Zuhörer damit auffordern, sich auf den neuesten Stand zu bringen. Der zusätzliche Aufwand (im Vergleich zur "fertigen"
FB-Lösung) belohnt Dich mit unbegrenzter Flexibilität, ist aber auch nicht ganz trivial, wenn man es das erste Mal macht. In beiden Fällen brauchst Du einen weiteren Port (3050 für
FB-Datenverbindung und einen niedrig privilegierten z.B. 30000 für die Events).
Aus H. Borries
"The Firebird Book" sei hier von S. 685 das Beispiel zitiert:
SQL-Code:
set term ^;
Create trigger post_new_order for table_sales
active after insert position 0
AS
Begin
POST_EVENT 'neuer Datensatz';
end^
set term ;^
Hier definierst Du für die Tabelle "tables_sales" einen Trigger, der nach jedem Einfügen/Insert ausgeführt wird. Der feuert dann das Event mit der Bezeichnung "neuer Datensatz" ab, das Du mit einer TIBEvent-Komponente am Client auswerten kannst. Simpel und effektiv und um es mit
Willy Astor zu sagen: "Probierstes, dann spürstes..."
--
Andreas