It is not that difficult to do, but it can get you into alot of trouble if you
do not set up the procedures/routines properly. I like your comment about a
dbkey system, it was started my down this path and was what led me to
developing a UID that is unique for every record in the database (and I bet
alot of you wondered why I described the surrogate key system yet did not
explain why I even bother).

It comes down to keeping track of what has been transfered - this comes back to
the UID's that I described in my documentation.
It definately takes more than a time stamp - expecially if a long running
transaction is kept open over a multi-day period.

I was not going to go into alot of details about it but I can include that
solution as well in my doc's.

best regards

Dalton

Jason Wharton wrote:

>
> Actually, this would be very difficult to do accurately inside of
> transaction context. Some of the records needing to go to the output might
> still be in limbo and get skipped. On a subsequent attempt how would one
> know what has been streamed out to backup and what ones were still
> uncommitted. The timestamp reflects the time of applying the DML not the
> time that the transaction became committed.
>
> I guess my point is you would need more than a timestamp and you would have
> to take into consideration that not all transactions are going to be
> serialized. In InterBase this just isn't something that you even consider.
> AFAIK.
>