> >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?

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.
--
Sicherer, schneller und einfacher. Die aktuellen Internet-Browser -
jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/atbrowser