Subject | Re: [firebird-support] Recovering deleted data |
---|---|
Author | Helen Borrie |
Post date | 2005-05-13T14:55:54Z |
At 01:46 PM 13/05/2005 +0000, you wrote:
accordingly. Don't write applications that delete rows from these tables.
Instead, for tables where it's essential to be able to recover data,
include a nullable timestamp column WasDeleted. When the client app wants
to request a Delete, make the statement "Update atable set WasDeleted =
current_timestamp where...". In all select queries and bulk updates,
include "WasDeleted is null" in the WHERE clause. When you need to
"undelete" a row, just update it again, setting WasDeleted to null.
You can purge these tables periodically by selecting rows on a date-range
for WasDeleted and permanently deleting them. If needed, they can be
copied to history tables first. From a housekeeping POV, it's a good idea
to do these purges just before a backup. As long as you remember to commit
the work, the backup will clear out the garbage left behind by the deletions.
If necessary, write BeforeDelete triggers to test current_user and except
out of the deletion if the wrong user is trying to do a physical
deletion; or set user privileges to determine which users are allowed to
delete rows from these tables.
./heLen
>Hi,If you have a business requirement to be able to this, then design
>
>If a row is deleted from a table, is there any way of recovering the
>deleted data? Presumably one method would be to use triggers, which
>backup any deleted rows to a new table. But are there any features
>within Firebird that allow data to be recovered?
accordingly. Don't write applications that delete rows from these tables.
Instead, for tables where it's essential to be able to recover data,
include a nullable timestamp column WasDeleted. When the client app wants
to request a Delete, make the statement "Update atable set WasDeleted =
current_timestamp where...". In all select queries and bulk updates,
include "WasDeleted is null" in the WHERE clause. When you need to
"undelete" a row, just update it again, setting WasDeleted to null.
You can purge these tables periodically by selecting rows on a date-range
for WasDeleted and permanently deleting them. If needed, they can be
copied to history tables first. From a housekeeping POV, it's a good idea
to do these purges just before a backup. As long as you remember to commit
the work, the backup will clear out the garbage left behind by the deletions.
If necessary, write BeforeDelete triggers to test current_user and except
out of the deletion if the wrong user is trying to do a physical
deletion; or set user privileges to determine which users are allowed to
delete rows from these tables.
./heLen