Any ideas about this?

Thanks!

Jonathan Neve.

Jonathan Neve wrote:

>Hi!
>
>I have a feature request to make; if this is not the right place to do
>so, please tell me where to go!
>
>So here it is. Why not create a sort of "undo-after-commit" feature,
>whereby old versions of a record could be kept indefinitely, and if
>necessary, restored of viewed?
>
>What might be good would be some sort of trace file, in
>which, all obselete record versions are dumped, as and when they become
>obselete. Then, there could be a simple API (or perhaps an SQL
>extention) that could be used for loading old record versions back into
>the DB, and also for purging out old versions periodically...
>
>Of course, we can't make the restore process entirely
>automatic, as that might make it unusable in complex cases.
>Perhaps the best thing would be a syntax similar to the following :
>
>CREATE TRACE (or some other name...) <NAME> [PARAMS];
>
>SELECT <COLS> FROM <TRACE_NAME>(<TIMESTAMP>).<TABLE_NAME>;
>INSERT INTO <TRACE_NAME>(<TIMESTAMP>).<TABLE_NAME> (<COLS>) VALUES
>(<VALUES>);
>ETC...
>
>This sort of thing would be good. It's true that if we make things
>completely automatic, it will be unasable. But if we simply make the
>tables the backup contains accessible, based on a certain timestamp,
>then after that, it could be manipulated as though it were an ordinary
>part of the database, allowing you to be as flexible as you need to be.
>
>This could use the same syntax as that which will be used if/when it
>becomes possible to access an external database simultaneously (I think
>I heard talk of this perhaps getting implemented one day). The backup
>could be treated just as though it were an external database, except
>that it would be read-only, and there would be no triggers nor procedures...
>
>