Jim Starkey wrote:

>Jonathan Neve wrote:
>
>
>
>>Any ideas about this?
>>
>>
>>
>>
>>
>>>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...
>>>
>>>
>>>
>>>
>>>
>This has come up about a dozen times over the years, often in the
>context of rolling back to an earlier revision of a CAD project.
>
>

Hmm. Doesn't sound too promising... :-)

>Everytime we've look at it in depth, we've come to the same conclusion,
>which is that the application semantics need to be a great deal richer
>than can be provided by a low level hack and vary signficantly from
>application to application.
>
>

Well, yes, I can understand this. I understand that something like
rolling back to a previous version of the database, in one smooth, neat
operation would be impossible to do at a low level, since the database
structure isn't known at that level.

However, wouldn't it be possible to simply keep the old record versions,
and _make them accessible_, through a simple syntax? I don't mean that
the database should automatically be able to do any kind of restoration,
but simply that it could be made accessible, exactly as though (from the
end-user perspective), it were simply another table, against which a
subset of the standard SQL statements could be executed.

Perhaps this is a simplistic approach, I'm no expert at this; but if
so... in what way?

Why wouldn't the syntax I proposed in my post (or something of that
sort) be usable? It seems to me that it would be in effect, just as
though we were accessing an external database (which feature, if I
understand correctly, is being planned on).

Why wouldn't this work?

Thanks!

Jonathan Neve.






[Non-text portions of this message have been removed]