At 01:53 PM 13-05-02 +0100, Dave Bullar wrote:

>""Helen Borrie (TeamIBO)"" <helebor@...> wrote in message
>news:5.1.0.14.2.20020513215511.0486f5c0@......
> > >Now as local database A acesses this queue does the data vanish? What
> > >happens when at a different instant, local database B accesses the queue
>?
> >
> > Are you replicating from database A (source) to database B (target)?
>No I am replicating from a 'central' database to A and to B at different
>instants.
>
> >
> > >Or must the sync action occur at all local databases at the same time ?
> >
>In other words must all the satelite databases be listening at the same time
>and a gun goes off and every one gets a string of updates etc.Or can each
>database work in its own time at being updated from the central database?
>If the latter (and it seemed to be the case because the scheme is that each
>replicated database is updated when it is otherwise idle) I dont understand
>the concept of the source having only one queue.
>I would like to get to grips with the 'events' that arise and what the
>'effective pipline mechanism' as Jason describes it is.
>
>If there are 10 records in the source queue of which satellite A needs all
>but satellite B only needs 5 because it got the others earlier ?? You see
>my mind is boggling :-}

oh...interrrresting....
but doable, I think. The replication process itself should take care of
ignoring, i.e. not updating, rows that are not different, since each "act
of replication" uses the latest data in both databases to make that
decision. It doesn't store values, only keys, and columns that
changed. Jason will have to comment on how the "mashing down" of changes
would work if it was likely to affect different outlier databases in
different ways.

What's needed is a flag on the queue record saying "Don't delete me", that
determines when the last database has received its update to that
record. It should be sufficient just to add a smallint to each change
record, that the outlier increments; and add a trigger to the replication
record that says "self-destruct if my reference count = n".

More housekeeping to code in, too. What happens if an outlier fails to get
the update; or if something goes wrong and one or more need to get it
again? You might be looking at keeping history against this eventuality,
to avoid a big clog-up; that said, even if one outlier missed out for a
few days, when it comes to the point of being online again, they don't need
all the stuff that happened betweentimes, but just the latest picture...

Brainstorming, really. <g>


regards,
Helen Borrie (TeamIBO Support)

** Please don't email your support questions privately **
Ask on the list and everyone benefits
Don't forget the IB Objects online FAQ - link from any page at
www.ibobjects.com