Jason,

> Boguslaw,
>
> The benefit you state is being able to roll-back the data to a point in

time

> or view the data "as was". It could work, you could write the code to be
> able to:
> 1) View DB as a read only connection as if you are transaction ABC => a
> time.
> 2) Rollback to a transaction number.
>
> The problem here is that rolling back to a time depends heavily on the
> commit time, not the TX start time. The TIP page is AFAIK a couple of

bits

> per transaction in an array of transactions. To add a commit number (=>
> timestamp) would be a fair amount of work and space usage. Alternatively
> you could make a copy of the TIP and store in a BLOB every minute I guess.

Interesting I thought about the same.What about records ? They have
transaction id I think.The idea was not to allow database engine to replace
old comitted versions of record with new one (and as regard we can have all
information : new comitted value of record ,old values and rollbacke'd
versions).As an extend to this idea I think about others:
1. sweep database could delete also those committed old versions of record
(remember - I think at user point of view, assume that I'm database admin
and after users confirm that the day is closed without problems I could
sweep database)
2. before making backup ,gbak could save those old versions into some
internal table in database like You mention ( we can now more options : we
can rollback database state to previous backup or restore current backup and
run redo log to rollback to some time after last backup and before current
backup)
3. sweep database could not sweep shadow database which could stand as
external replica and/or redo log

> Anyway, I think the benefits of this over "shadowing", "clustering",
> "incremental backups", all of which require a plug-in at about the same
> point, deliver more benefits. Do you agree?

Yes.

Best Regards
Boguslaw