At 11:36 PM 17/03/2004 +0000, you wrote:

>I need firebird to notify each client when a certain "event" (for
>lack of a better term) occurs on a table. Basically, here is what I
>am aiming for and I am very new to FB so I need to know if it can be
>done.
>
>10 computer network. Each computer does a query which returns a set
>of records matching a specific date that they are looking at. When
>one computer (client) has its set of data (say 30 records) it
>generates a string grid to represent that data. That screen may just
>sit there for hours. If one of the other clients inserts a new record
>into the table that would match the query set, I need FB (or the
>other client) to be able to notify my computer that a new record has
>been inserted. I need the same thing to occur if a record was deleted
>or modified that is in my query set.

If you use Read Committed isolation, the server takes care of updating
those transaction "purviews". It is up to your application code to ensure
that it refreshes the current view in a timely fashion.

>There could be dozens of computers "looking" at the same set of data
>in their queries and if one computer deletes, modifies, or inserts
>something that would affect that query set, I need all the affected
>computers to be able to either be notified of the specific change
>(insert, modification, or deletion) or at the very least be told to
>refresh the query.

This is done with a notification engine coordinating client and server. On
the server side, it involves triggers. In the client app, it involves
implementing a notification channel that client apps can be told to send
messages to and receive messages from. For a "here's how" discussion of
such a mechanism already done and encapsulated in component classes,
download the TI sheet on DML Caching from www.ibobjects.com/TechInfo.html.

Of course, all this extra overhead will be very costly if you implement it
blindly for everything. In the general course of events, the
"client/server way" is to set isolation levels and lock wait conditions in
such a way that it is only necessary to respond when a conflict *actually*
occurs.

This is of major concern in your application design:

"When one computer (client) has its set of data (say 30 records) it
generates a string grid to represent that data. That screen may just
sit there for hours."

We are not talking desktop computing here!! If you have datasets that
"just sit there for hours" then they need to be in read-only,
read-committed transactions, or your users are going to want your guts for
garters. Notifications (along the lines of DML Caching) are ideal for
alerting read-only transactions of the need to refresh the clients'
datasets in response to external changes.

/heLen