Subject | Re: [firebird-support] Firebird/ASA/Clarion |
---|---|
Author | Alexandre Benson Smith |
Post date | 2004-04-02T14:55:31Z |
At 12:12 02/04/2004 +0200, you wrote:
What about if you create a history table, or dead_table, that will be feed
by an after delete trigger on the mains table, this dead records table
should have the same structure plus aditional information (like delete
date/time, user, anything you think you need to keep).
If you need to restore it... just pump it back from the dead_records_table
to the main_table.
Or create a flag on the records marking it as deleted, and from time to
time delete all records that are marked as deleted and are delete after X
days...
I use to have an undo method in my systems, it's usual that a delet is just
not a delete from a table, the delete should be a process, when you delet
something this should modify other tables, sums, totals, and so on... so if
this deletion is wrong, the hole "delete process"should be reverted. So I
have a Process to Delete/Undelete a record.
One other thing, I think I don't have a lot of tables that don't have
references (referential integrity, or forced by some system rule) with
other tables, and this references should stop a deletion.
Hope you understand what I want to say...
See you !
Alexandre Benson Smith
Development
THOR Software e Comercial Ltda.
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br
----------
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.631 / Virus Database: 404 - Release Date: 17/03/2004
[Non-text portions of this message have been removed]
>I've had this sort of experience too! :-)Hi Jonathan,
>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.
What about if you create a history table, or dead_table, that will be feed
by an after delete trigger on the mains table, this dead records table
should have the same structure plus aditional information (like delete
date/time, user, anything you think you need to keep).
If you need to restore it... just pump it back from the dead_records_table
to the main_table.
Or create a flag on the records marking it as deleted, and from time to
time delete all records that are marked as deleted and are delete after X
days...
I use to have an undo method in my systems, it's usual that a delet is just
not a delete from a table, the delete should be a process, when you delet
something this should modify other tables, sums, totals, and so on... so if
this deletion is wrong, the hole "delete process"should be reverted. So I
have a Process to Delete/Undelete a record.
One other thing, I think I don't have a lot of tables that don't have
references (referential integrity, or forced by some system rule) with
other tables, and this references should stop a deletion.
Hope you understand what I want to say...
See you !
Alexandre Benson Smith
Development
THOR Software e Comercial Ltda.
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br
----------
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.631 / Virus Database: 404 - Release Date: 17/03/2004
[Non-text portions of this message have been removed]