Subject | Re: [IBO] Re: DMLCache and DMLCacheReceivedItem not fired |
---|---|
Author | Helen Borrie |
Post date | 2003-02-01T10:59:22Z |
At 08:24 AM 1/02/2003 +0000, you wrote:
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
>Thanks Helen, but my problem is that while the event "ReceivedItem" isMarco,
>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
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