Firebird has a feature called EVENT that you can use to notify clients of changes to the database. The idea is that when the data in the table changes, the trigger sends an event. Firebird takes care to notify all customers who have registered interest in the event by name. After notification, each client is responsible for updating their own data by querying the database.
The client cannot receive event information about new or old values. This is by design because there is no way to resolve this with transaction isolation. Also, your client cannot register for events using wildcards. Thus, you should fairly broadly develop your notification from the server to the client, and let the client update to see what exactly has changed.
See http://www.firebirdsql.org/doc/whitepapers/events_paper.pdf
You do not indicate which client platform or language you are using, so I cannot advise the specific API that you will use. I offer you Google, for example, "firebird event java" or "firebird event php" or similar, based on the language you use.
Since you are saying in a comment that you are using WPF, here is a link to a sample code for registering some .NET application code for event notification:
http://www.firebirdsql.org/index.php?op=devel&sub=netprovider&id=examples#3
Repeat your comment: Yes, the Firebird event mechanism is limited by the ability to transmit information. This is necessary because any information that it may carry can be canceled or canceled. For example, if a trigger dispatches an event, but then the operation that generates the trigger violates the restriction by canceling the operation, but not the event. Thus, events can only be a kind of “hint” that something interesting could have happened. Other customers should update their data at that time, but they are not told what to look for. This is at least better than a survey.
So, you basically describe the publishing / subscribing mechanism - the message queue . I'm not sure that I will use RDBMS to implement a message queue. It can be done, but you basically reinvent the wheel.
Here are a few message queue products that are well regarded:
This means that when one client modifies data in a way that others may be aware of, that client must also send a message to the message queue. When consumer customers see a message that interests them, they know to update their copy of some data.