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

>
> >
> > I need transaction 4 to know that pkey=3 is the last record that can

be

> > cronologically copied to my destination database.
> > I know transaction 4 can see pkey=5 and pkey=6, but it shouldn't

copy

> > those records until previous records (in this example pkey=3) are
> > commited.
> > The replication process is started periodically. So hopefully, next
> > time it starts, transaction #3 will already be commited and records
> > 4,5,6 will be copied.
> >
> >
> It won't see pk3 if pk 3 records are not committed.
> I think you're missing the point. Whatever state the the comitted DB

is in,

> it's in a consistent state. Whenever your replication process starts

it sees

> commited records (including your audit table). Your replication

process can

> safely process those records there and then.
> Why don't you download the source of fbreplicator at www.meta.com.au,

you

> will see quite clearly, the logic behind replication.
> Alan

Thanks Alan, I'll download the source and take a look at it.

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
sent record. The problem is that sometimes when the process starts there
are some uncommited records in the audit table between other commited
records. In this situation the process sends all visible records and
saves which record is the NEW "last sent record". Sometime after the
replication ends, those uncommited records are commited and are never
sent since they got primary keys previous to the new last sent record.
This is why I must only send those audit records which have primary keys
that are previous to the uncommited records.

Hope this clarifys my problem.

Thanks.