Hello Helen

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

> At 09:24 PM 17/09/2004 +0000, you wrote:
>
> >I wonder if it would be possible for the firebird developers to
> >modify the event listener regisration code so that a client

listening

> >for events could register for events such as 'MY_EVENT*' and then

be

> >sent all events with names matching 'MY_EVENT*'?
> >
> >I think this capability would be benefical to both of us.
> >
> >For example: ...
> >
> >At present the server-side event notification is triggered by the
> >invocation of POST_EVENT 'ANYNAME'
> >There seems to be no possibility (please correct me anyone if I am
> >wrong) to send an addittional parameter with 'ANYNAME', such as
> >sending back a key for the record just inserted or updated. Inside
> >the trigger or procedure calling POST_EVENT the event name can
> >be "mangled" to produce "ANYNAME:1234567" but this changes the name
> >of the event and on the client side only a client who has

registered

> >as a listener for an event named "ANYNAME:1234567" wil be notified.
> >
> >By contrast if a client could register as a listener for events
> >like 'ANYNAME*' then they would get notice of
> >event "ANYNAME:1234567", peel off the key value "1234567" and

process

> >the event 'ANYNAME' as they wish.
> >
> >So here is a simple case for expanding the event notification code

to

> >allow for registering for events named with wild card names.
>
> Isn't this the opposite of what you asked for? You said you wanted

your

> client to be able to *ignore* any events that had been fired by its

own

> process.

Using the wild card event scheme a client would get messages fom
events caused by themselves but would, by virtue of a code appended
detect the event was their event and do nothing. It is sufficient for
my needs that events identify the client causing the event.

>
>
> >Is there a way to achieve this functionality with using the

existing scheme?

>
> You can already send an event that includes the user name (listen

for/send

> from server), e.g.
> ...
> declare ThisEvent varchar(15) = '1234'||CURRENT_USER;
> ...
> ...
> POST_EVENT(ThisEvent) ;

This won't satisfy my requiremnt for a client to listen, for example,
for all insertions to a table as I cannot assume a client will know
who the CURRENT_USERS are at any one time, nor even how many users
there are.

>
> (provided your system has very short user names! Event names are

limited

> to 15 bytes )

There is an addition for Chapter VII of "Firebird Book"; but the 15
char length of event anmes is explicit on page 684.

>
> Since the client application knows its username, you already have

the

> capability to have a client listen for its own events. But that's

no good

> for the generic purpose of events, which is to have everyone listen

for an

> event. If only the instigating client knows the name of the event,

none of

> the others knows what to listen for. If you add your original

requirement -

> to have the client ignore its own events - then this user-specific

event

> has nowhere to go.

Ah yes you saw this too.

>
> Whether it would be a Good Thing to re-architect events to make

them a

> full-blown messaging subsystem isn't a subject for the support list

but one

> you might care to raise on firebird-architect, if you have strong

feelings

> about it.

Perhaps I'll try to make a case for it there as a hopefully simple
extension to Firebird code.

>
> Since (I think!) you are using IBO, why don't you just use

DMLCaching? If

> I've understood your requirements, it already implements exactly

what you

> want: clients listening for DML commits and optionally ignoring

their own.

Yes I am using IBO, I do not know of DML Caching so I'll look it up.
By reading the IBO help manual, and I have trouble understanding it,
DML Caching can sync changes made in datasets using a common
transaction. So this won't serve to inform one instance of my program
if another instance changed something in a table as their
transactions will not be common.

Thanks

Russell

>
> ./heLen