Firebird ha una funzionalità denominata EVENT che è possibile utilizzare per notificare ai client le modifiche al database. L'idea è che quando i dati in una tabella vengono cambiati, un trigger pubblica un evento. Firebird si occupa di notificare per nome tutti i clienti che hanno registrato un interesse nell'evento. Una volta notificato, ogni cliente è responsabile di aggiornare i propri dati interrogando il database.
Il client non può ottenere informazioni dall'evento sui valori vecchi o nuovi. Questo è di progettazione, perché non c'è modo di risolvere questo problema con l'isolamento della transazione. Né il tuo cliente può registrarsi per eventi usando i caratteri jolly. Quindi devi progettare la tua notifica server-to-client in modo piuttosto ampio e lasciare che il client si aggiorni per vedere cosa è esattamente cambiato.
Vedi http://www.firebirdsql.org/doc/whitepapers/events_paper.pdf
Non accennate quale piattaforma client o la lingua che si sta utilizzando, quindi non posso consigliare l'API specifica si usa. Ti suggerisco google ad esempio "firebird event java" o "firebird event php" o simili, in base alla lingua che stai utilizzando.
Dal momento che si dice in un commento che si sta utilizzando WPF, ecco un link ad un esempio di codice di codice .NET registrazione per la notifica di un evento:
http://www.firebirdsql.org/index.php?op=devel&sub=netprovider&id=examples#3
Per il tuo commento: Sì, il meccanismo degli eventi di Firebird ha una capacità limitata di trasportare informazioni. Questo è necessario perché qualsiasi informazione che potrebbe contenere potrebbe essere cancellata o ripristinata. Ad esempio se un trigger registra un evento ma l'operazione che ha generato il trigger viola un vincolo, annullando l'operazione ma non l'evento. Quindi gli eventi possono essere solo una sorta di "suggerimento" che possa essere successo qualcosa di interessante. Gli altri client devono aggiornare i loro dati in quel momento, ma non gli viene detto cosa cercare. Questo è almeno meglio del polling.
Quindi stai praticamente descrivendo un meccanismo di pubblicazione/sottoscrizione: una coda di messaggi . Non sono sicuro di utilizzare un RDBMS per implementare una coda di messaggi. Può essere fatto, ma in pratica stai reinventando la ruota.
Ecco alcuni prodotti delle code dei messaggi che sono ben considerato:
Ciò significa che quando un cliente modifica i dati in un modo che altri potrebbero aver bisogno di sapere, anche il client deve inviare un messaggio alla coda dei messaggi. Quando i clienti consumer vedono il messaggio a cui sono interessati, sanno di aggiornare la loro copia di alcuni dati.
È la vostra aspettativa che il client venga detto cambia in qualche modo "spinto" (più forse notifica), o meglio (e più facilmente fatto ...) che dopo lo spostamento, spostandosi nei risultati impostati e generalmente interrogando il database di nuovo otterrebbero gli ultimi dati? – mjv
Sto pensando più a uno scenario di associazione, visto che il mio front-end è in WPF. – luvieere