Thanks so much Helen for pointing me to the explanation of
DMLCaching. The part I may be able to use is "Global DMLCaching". I
have read those notes and do not meet the requirements for GLobal DML
Caching but I am not sure how important Jason's requirement "Your
user management system must make provision for each user to be
recognized distinctly." really is. If it is essential I can't use
Global DML Caching as all my apps login to the database with the same
name. Internal to the program I keep track of users. I may be able to
use the IBO$DMLCache table's columns to identify users.

Russell

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

> At 05:33 AM 18/09/2004 +0000, you wrote:
> > >
> > > 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.
>
> No, the reverse: different transactions. In the scope of a single
> application, it could be used to synchronise datasets; but

DMLCaching can

> be scoped across application and connection boundaries. There is a

TI

> sheet at www.ibobjects.com/docs/ti_dmlcaching.ZIP.
>
> >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.
>
> That's *exactly* what the DMLCaching notification system is

designed to do.

>
> ./heLen
>
>
>
> >Thanks
> >
> >Russell
> >
> > >
> > > ./heLen
> >
> >
> >
> >
> >
> >Yahoo! Groups Links
> >
> >
> >
> >