--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@t...>
wrote:

> 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

All we are doing is a query on an Appointment table. Returns the time
and length of each appointment on a specific day. Then I take the
values out of time and length to generate the string grid and paint
it in all the pretty colors. All I am doing is reading info from the
query set...never modifying or deleting or anything like that. As
soon as a different computer adds a new appointment to the day I am
looking at on my computer, I need my computer to add that appointment
to the string grid.

There are "manual" ways to do this by having a table with all unique
terminal id numbers indicating the date currently being viewed and
then any time a client computer does anything for a specific date, it
looks through that table and sends messages to the other clients on
the same date using sockets or some other method but I was hoping to
figure out a way to do it on the server.

It is important to note that for our biggest client right now we are
probably only talking about 300 appointments a day over a 12 hour
period so it isn't like the event will be firing every 2 seconds or
anything and it would be extremely rare for all of the computers to
actually be looking at the same day...usually 2-3 on the same day
with the rest pointed all over the place.

And as for network traffic...they are currently being forced to use
DBF files (over 2GB worth of them) and tTables in a NON-client/server
environment. You want network traffic??? Anything has to be an
improvement over that. Their server has 8 P-IV processors and 16GB of
ram so I am pretty sure this will be a vast improvement for them.

Trevor