At 05:09 AM 25/11/2004 +0000, you wrote:

>Hello newsgroup:
>
>I am trying to figure out how to use IB_Events. I am trying to alert
>all users to log off as a backup was scheduled in 10 min. The plan
>is to trigger an SP on the server that posts an event that the
>IB_Event component in client machine recognizes, which then triggers
>a windows ShowMessage dialog box. At present, this is as far as I
>can go, as the use of the event system is not entirely clear to
>me...any help or pointers to other resources would be helpful.

You probably have just about all of it already. :-))

The event system is really very simple in what it actually does. If you
call POST_EVENT in a SP, the server sends to the event manager subsystem
(which is just a routine maintaining a table in memory) a message that is
nothing but the name of the event. Any connections that were listening for
that event will get a notification of it.

On the client side, just drop in an IB_Events for each group of events you
want the client to listen for. One IB_Events can listen for up to 16
events. It's quite OK to use one ib_events for each event if you want.

Use the Events property (a TStrings) to list the names of the events you
want to listen for. Match up the names with the names you assign in the
PSQL code. IMO, it's a good idea to match for case, though they're not
meant to be case-sensitive. It just seems tidier for tracing purposes.

Write your response code in the OnEventAlert handler, e.g. your popup
warning, any counts or timings, variables for your message, etc. If you
are going to run the SP multiple times, then the users will get multiple
alerts. On the client side you can set an interval for how often the alert
flag gets checked, and "nag", with a reducing time limit, or
whatever. Possibly you'll want to set things up so that the user gets the
popup every fifth time, or something like that.

When you want the client to start listening for the Event, call the
ib_Events RegisterEvents method. To switch off listening, call
UnregisterEvents. You can play around with the properties to make the
alerter behave however you want it.

Don't forget that events don't fire on the server until the transaction in
which they occur is committed; and they don't fire at all if the SP fails
or the transaction is rolled back. If you have some kind of daemon on the
server repeatedly running this SP on a schedule, make sure you commit the
SP immediately after it runs. (A tib_dsql in your server-side program, in a
transaction with ServerAutocommit, should be your friend here. Just make
sure that you watch things like overflows and other stuff that can cause
run-time exceptions. :-)).

Oh, and make sure there is a port open in your firewall for the event
traffic. Events move in mysterious ways - they don't use the same port as
the connection, but search at random for a port that is open at both
ends. (In Firebird 1.5 you can earmark a port specifically for this with
the RemoteAuxPort parameter. The default of 0 follows the traditional
random port behaviour).

Helen