--- In firebird-support@yahoogroups.com, "Mark Rotteveel"
<Avalanche1979@...> wrote:

>
> > >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.
> >
> > Hi Francisco! Why not have a SENT_AUDIT_RECORDS table (containing

the PK

> > of the record and the ID of the destination database) rather than
> > SENT_AUDIT_RANGES? I just think it is simpler to work with Firebirds

concurrency

> > rather than against it. Or is there a logical reason for making

uncommitted

> > records prevent committed records from being transferred?

This is an approach I've been delaying form months. Just before reading
your reply I started creating and using a SENT_AUDIT_RECORDS table,
similar to what you've described.
The reason for preventing committed records from being transferred is
that I currently send pending records following the last sent range.
So if that last range now contains newly commited records that weren't
there when I sent that range those new records wouldn't be sent.
Thanks Svein.

> A range would still be usefull, if the actual ranges sent are stored:
> eg if I send 1,3,5,7,8,9 then I have four ranges: 1-1, 3-3, 5-5, 7-9,

not one : 1-9.

> If Francisco is currently storing the latter that could be part of the

issue.

Yes, I am storing the complete range. Your partial ranges aproach could
lead me to other issues:
Problem 1 : Since audits get their primary key from a generator on
transactions that may or may not be commited, I can't be sure about
audits 2,4 and 6(they could never be commited).
Problem 2: my current algorithm sends all pending records following the
last sent range. I would have to change a lot of this method to search
all those audits that could be between ranges(and could not even exist).
Thanks Mark.