Jonathan Neve wrote:

> Martijn Tonies wrote:
>
> >>Did we hear a sigh-of-relief here ?
> >>
> >>
> >
> >Sure did...
> >
> >Anyway, no need for a log-file. Just used the transactions :-)
> >
> I've had this sort of experience too! :-)
> I agree that transactions go a long way to avoiding such problems. OTOH,
> I have also know a few cases where a customer phones me up to say that
> they deleted a record by mistake. I try to be polite and not ask the
> obvious "err... why did you do that?!?"... :-) So I ended up having to
> restore a backup, and pump an old version of the record back to the DB.
> So it went ok, but I can understand the potential usefulness of some
> sort of "Undo-after-commit" feature, or something like that...
>
> Or else, what might be good would be something like a shadow 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...
>
> Please, no flammes if this is yet another horrendous idea! :-)
>
> Jonathan Neve.
>
>
> [Non-text portions of this message have been removed]

OK, i also give my 2cents:

You have the Problem, that you need records witch really were deleted,
it's what i would call bad database design.
Why not do it in the following way:
Do not physically delete records. Mark them deleted.
This way you can still have the log of user-deletes. Sometimes
you will need it because for example in the bankers-business you have
to be able to tell from whom and when a record was deleted.
There are soo many possibilities to do this kind of work, that
i do not want to cont them now, but i really had to do it this way.

What do you think about this way to do it?

Uwe