Firebird tiene una función llamada EVENT que puede utilizar para notificar a los clientes de los cambios en la base de datos. La idea es que cuando se cambian los datos en una tabla, un activador publica un evento. Firebird se encarga de notificar a todos los clientes que han registrado un interés en el evento por su nombre. Una vez notificado, cada cliente es responsable de actualizar sus propios datos al consultar la base de datos.
El cliente no puede obtener información del evento acerca de los valores nuevos o antiguos. Esto es por diseño, porque no hay forma de resolver esto con el aislamiento de transacción. Tampoco su cliente puede registrarse para eventos usando comodines. Por lo tanto, debe diseñar su notificación de servidor a cliente de manera bastante amplia y dejar que el cliente se actualice para ver qué cambió exactamente.
Ver http://www.firebirdsql.org/doc/whitepapers/events_paper.pdf
Usted no menciona qué plataforma o idioma del cliente que está utilizando, por lo que no puede asesorar sobre la API específica que usaría. Le sugiero que busque, por ejemplo, "firebird event java" o "firebird event php" o similar, según el idioma que esté utilizando.
Desde que usted dice en un comentario que está utilizando WPF, aquí hay un enlace a un ejemplo de código de un código de aplicaciones .NET registrarse para la notificación de un evento:
http://www.firebirdsql.org/index.php?op=devel&sub=netprovider&id=examples#3
Re su comentario: Sí, el mecanismo de evento Firebird es limitado en su capacidad para transportar información. Esto es necesario porque cualquier información que pueda contener podría cancelarse o retrotraerse. Por ejemplo, si un activador publica un evento pero luego la operación que generó el activador viola una restricción, cancela la operación pero no el evento. Entonces los eventos solo pueden ser una especie de "sugerencia" de que algo de interés puede haber sucedido. Los otros clientes necesitan actualizar sus datos en ese momento, pero no se les dice qué buscar. Esto es al menos mejor que las encuestas.
Así que básicamente está describiendo un mecanismo de publicación/suscripción - una cola de mensajes . No estoy seguro de que use un RDBMS para implementar una cola de mensajes. Se puede hacer, pero básicamente estás reinventando la rueda.
Éstos son algunos productos de colas de mensajes que están bien considerados:
Esto significa que cuando un cliente modifica los datos de una manera que otros pueden necesitar saber, ese cliente también tiene que publicar un mensaje en la cola de mensajes. Cuando los clientes de consumo ven el mensaje que les interesa, saben actualizar su copia de algunos datos.
¿Su expectativa de que el cliente obtendría dichos cambios de alguna manera "les empujó" (más tal vez notificación), o mejor dicho (y más fácilmente ...) que al actualizar, moverse en el conjunto de resultados y generalmente consultar el ¿Nueva base de datos obtendrían los últimos datos? – mjv
Estoy pensando más en un escenario de enlace de datos, ya que mi front-end está en WPF. – luvieere