Subject RE: [IBO] Refreshing Data
Author Helen Borrie
At 08:50 AM 12-03-01 -0500, you wrote:
> > That´s easy Paul,
> >
> > use IB events (TIB_Events encapsulates the raw api) and you get a
> > message if the lookup table has changed. Define after delete, after
> > insert, after update triggers in that table which must post the event.
> > Your clients must register for this event, see IB Programmers Guide. I
> > have a similar problem and dont´t want to refresh the whole query but
> > only the inserted row or the incremental change of the dataset.
> > Unfortunatedly the event can´t tell the row. Does anybody know a
> > sophisticated solution (better than: the inserting application sends
> > the row via sockets to the clients)?
>That's the easy solution? That sounds really really ugly, I was
>hoping for something IBO based.

"IBO based" really means "data based" and "database-based" and you need DML Caching here. The events notification system is not as ugly as you think it is. It is beautifully encapsulated in the DML Caching features. The catch here is that you really need to work a bit harder on the code to take advantage of it with the TDataset/TDatasource compatible components. You'll need to take charge of the TIBOTables' InternalDataset property and use casting to get at the properties.

There is a Tech Info sheet on DML Caching - let me know if you are interested.

>The problem as I see it, is that
>each form is an MDI Child, so it lives entirely on the stack. So it
>would need to be able to do this dynamically. I guess I need to
>think up plan B.

No: none such awkward, client-driven mularkey. IBO's DML Caching does it all with events and triggers and it can even be used to keep different clients in synch with one another.


>Paul Schmidt,
>Tricat Technologies
>Email: paul@...
>Your use of Yahoo! Groups is subject to

All for Open and Open for All
InterBase Developer Initiative ·