Shame on me :((
My "base table editing form" had a transaction component that, I don't
know why, had a tiConcurrency isolation level :(
I've changed it to tiCommitted (the level I always use for this kind
of editing, so I did not check it until now) as suggested by Thomas
Steinmaurer in his first post and everything works!
But I think that some documentation has to be improved. My setup
should have been correct because I need things work that way, but as
far as I remember, is not obvious from the tech-sheet nor the help
file that:
a) you have to explicitly commit changes, autocommit is not enought if
your datasets are chained with different transactions
b) you have to set transactions to tiCommitted.
Helen, can you chack it and fix it?
I thank you all for the help, I was in real troubles without DMLcache
working properly.
regards
Marco Menardi

--- In IBObjects@yahoogroups.com, Helen Borrie <helebor@t...> wrote:
> At 08:24 AM 1/02/2003 +0000, you wrote:
> >Thanks Helen, but my problem is that while the event "ReceivedItem" is
> >fired for the table with the same keylinks, it's not fired in the
> >table that is a many-to-many relation between that table and another
> >one, so I can do nothing to refresh the dataset.
> >I was thinking that the "edited" event was broadcasted to all the
> >connected dataset, while seems that it's broadcasted only to those
> >with the same keylinks, that is not enought for all the situations
> >where you have a join, or like in mine, you have a many-to-many
> >relation that involves those fields + the ones of the other table.
> >Since this seems strange to me (and it's contrary to the help file
> >sample that confirms tha the ReceivedItem is broadcasted to all the
> >datasets) I was wondering if there is some flag or something else that
> >has to be set in this particular situation.
> >thanks
>
> Marco,
> I can't tell where you are with this setup. Are you using the
> DMLCacheFlags settings on the datasets?
>
> TIB_DMLCacheFlags = ( dcfAnnounceEdit,
> dcfAnnounceInsert,
> dcfAnnounceDelete,
> dcfReceiveEdit,
> dcfReceiveInsert,
> dcfReceiveDelete );
>
> Include the flags you want, exclude those you don't. Announce on
the ones
> that are likely to be edited, Receive (notifications) on the ones
that need
> to synchronise with the Announced operations.
>
> From the help:
>
> DMLCacheFlags
> This property controls how a dataset interacts with the DML cache of
its
> transaction in order to synchronize changes between datasets
automatically.
> Applies to
> TIB_Dataset
> Declaration
> property DMLCacheFlags: TIB_DMLCacheFlagsSet;
> Description
> It is possible to override the default behavior by using the
> OnDMLCacheAnnounceItem and OnDMLReceiveItem events. Otherwise, the
KeyLinks
> columns and values are used by default.
>
> So you see, you can get around the default Keylinks notification
chain, by
> going into the DMLAnnounceItem and telling the notification to poll
using
> some other column(ns) for the linkage. Similarly, you can intercept a
> ReceivedItem and specify an alternative column for that linkage.
>
> If you have set flags but have keys that break the keylinks "chain"
> somewhere along the line, then there will be notifications that
won't get
> through.
>
> I don't know what your many-to-many structures look like but, for
example,
> if you are using a surrogate primary key on your intersection set, then
> this will be a place where you need to intercept the notification
with a
> ReceivedItem handler. Make the link between the announcing key and the
> matching column on that side of the Many:Many, and tie it to the
associated
> column on the other side of the Many:Many. In this case, you
potentially
> have multiple rows in the intersection set that are affected by the
> notification and hence, multiple rows on the other side that are
affected.
>
> From the problem description, I can't tell whether you have set up
your
> "telecommunications" according to this model and are failing to get the
> expected notifications...or what....
>
> Helen