--- In firebird-support@yahoogroups.com, "Alan McDonald" <alan@...>
wrote:

>
> >
> > I think I need to explain a little bit further my problem.
> > When the replication process starts it looks on another table which

was

> > the last record sent from the audit table to the destination

database.

> > The process should send cronologically all records following the

last

>
> actually the chronology isn't or shouldn't be relevant. if a record is
> inserted and then updated 15 times, it's the last, most recent

committed

> update which is relevant. The fact that you replicate that same record

more

> than once in a replication cycle is also irrelevant. IN this case, you

would

> replicate the insert once, then replicate the update 15 times with

exactly

> the same content. All you need to do is manage the inserts first, then

the

> updates then the deletes. So if your source finally deletes the record
> before a repl cycle begins, the record will be inserted, updated 15

times,

> then deleted.
>
> > sent record. The problem is that sometimes when the process starts
> > there
> > are some uncommited records in the audit table between other

commited

>
> if they are uncommitted, then they can't be seen so the repl engine

can't

> act on them.
>
> > records. In this situation the process sends all visible records and
> > saves which record is the NEW "last sent record". Sometime after the
>
> the engine should use a 2 phase commit and finally delete the the

audit

> record after taking appropriate action. The audit table is or should

be

> empty after a repl cycle.
> Alan

Thanks for helping Alan.

I have MULTIPLE destination databases and my central repository sends
and receives data to and from every destination.
I can't delete audit records after sending them. I could delete them
only after every destination has received those records.
When a destination receives a range of audit records, I save the first
and last pkey of the range on a SENT_AUDIT_RANGES table, with an id of
the destination database.
If inside that range there were uncommited records(audit records get
their primary key from a generator) during the sending transaction,
those records will never be sent, since that range will be marked as
sent.
So, chronology is relevant because I should only send audit records
previous to the first uncommited audit record.

Francisco.