Subject Re: [IB-Architect] Super-transactions and Incremental Backup
Author dcalford
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


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.