|
Then stop deleting it if you still need it later!
If you throw away a chair permanently, how would you go and restore it? Answer: once it is really gone, you can't.
You can "export" the data, say in a CSV format - but that would merely be "recreating" the data in another place.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Quote: If you throw away a chair permanently, how would you go and restore it? Answer: once it is really gone, you can't.
A chair is not composed by bites or bytes.
And why you are getting an example from material world. This is a more closer example : A file may gone from Recycle bin , but it can be recovered.
|
|
|
|
|
satc wrote: A file may gone from Recycle bin , but it can be recovered.
There's no guarantee that it can be recovered. It may be overwritten by the filesystem at any time and be completely gone.
Those bytes have to exist somewhere in order to recover them. Once they're gone, you cannot recover, regardless of the tools you use.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
There is not guarantee , but it's possible.
so let's get this possibility to the database users too.
|
|
|
|
|
satc wrote: so let's get this possibility to the database users too.
You go do that 
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
You need to end your responsibility somewhere. You can't care for any and every eventuality. If you have a soft-delete then that is your recycle bin. Only "educated" users should be allowed to hard-delete soft-deleted entities and that should be the end of your/your software's responsibility. If something gets hard-deleted by accident then it's the user's fault and they will simply have to restore it manually.
If your client wants a second stage recovery then why doesn't he want a third stage recovery in case a recovery script gets deleted? It's BS. If you can't convince him of that, then rather implement a two-stage soft-delete than something like recovery scripts.
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
The windows file systems has only 2 levels : 1) Add to recycle bin / Restore from recycle bin 2)Delete from recycle bin / Restore using recovery software.
So , I would like to add only 2 recovery stages.
But sorry , as we spend time discussing if this is/ or isn't good to implement , why someone doesn't give an idea ( if exists of course ) to implement this ?
|
|
|
|
|
satc wrote: So , I would like to add only 2 recovery stages.
A two-stage soft-delete would kind of be like that. Another idea would be to require confirmation for hard-deletion from a second user.
satc wrote: But sorry , as we spend time discussing if this is/ or isn't good to implement , why someone doesn't give an idea ( if exists of course ) to implement this ?
Because we deem it as best advice to discourage from doing that and probably no one here has done something like that yet.
A complication you probably haven't thought of yet: If your database schema changes your recovery scripts become incompatible. If I would be pressed to implement something like this I would have a second database with an identical schema where I would store the entities which were hard-deleted from the main database. If the schema should change, the same schema transformation could be applied to the second database.
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
Quote: no one here has done something like that yet.
Well for everything there's a first time , don't you think ?
I've thought the idea for a second database , but I think will be very complicated.For example :
Record1- has childs but also is a child for another table.
I delete record 1 and its child.
But to put this on the second database , I need the parent of record 1 too ( which is not deleted )....
So I think the idea to have a kind of script that could create only the deleted record would be more easy.
|
|
|
|
|
satc wrote: Well for everything there's a first time , don't you think ?
Sure. But there's a reason why there's no "standard procedure" for this. Because it's a mess, regardless how you approach it. The day will come you regret you opened this can instead of telling your client not to hard-delete a record if he wants to be able to recover it or to leave it up to the DBA 
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
So :
" A problem difficult to resolve" = " It's better to not implement this" 
If the restoring is a useless feature , so maybe we can tell Microsoft to remove from file system too.
|
|
|
|
|
satc wrote: So :
" A problem difficult to resolve" = " It's better to not implement this"
Why attempt to implement in code something that
- is very complicated and prone to be buggy or to break with changes
- is likely to be used only very rarely
- can be solved in a different way* much easier ?
*: Through backups / DBA. If you want to care for the case that a record gets deleted before a database backup has run then simply disallow hard-deletion on the same day.
satc wrote: If the restoring is a useless feature , so maybe we can tell Microsoft to remove from file system too.
Restoring after emptying the recycle bin isn't guaranteed to succeed - it's likely that parts of the file have already been overwritten.
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
A database is not a filesystem, and no, it would not be very wise to start depending on a blob that "may or may not be" overwritten and hence, may or may not be recoverable.
satc wrote: " A problem difficult to resolve" = " It's better to not implement this"
I'm looking forward to your article on how you solved it
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: I'm looking forward to your article on how you solved it
Indeed
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
Well , I try it to resolve after getting a final word from you like this : " On my opinion there's no way to do this" . Can you claim this ?
|
|
|
|
|
As I tried to communicate with my previous replies, it's not impossible but far from economical.
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
satc wrote: I try it to resolve after getting a final word from you
You already had it several times, and I will think twice before getting involved again
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
No I didn't .
All I get from you is with simple words " ... it's not good to do this".
Give me a clear post : " ..for my opinion , this can't be done at all..."
Anyway , I think to try with another database that is identical with the main database , except that has no relationship. This will help to save a deleted record even when the parent is not deleted. But to find the parent , on the table will be a column that will contain the parent's table name..... That is for the moment.
|
|
|
|
|
satc wrote: Give me a clear post : " ..for my opinion , this can't be done at all..."
Sure it can be done
satc wrote: That is for the moment.
You're welcome, have a great day 
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
You really need to try and limit your over engineering of the systems. If it is your client requiring this type of functionality you need to educate them. If it is yourself trying to meet every conceivable scenario you need to take the advice of more experienced developers.
Use the soft delete flag suggested, if the user then hard deletes TOUGH luck, they need to take responsibility for their actions. In 25+ years of LOB applications I have never had to implement such a system as you are proposing.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
I respect the opinions of more experienced developers.
That I doesn't accept , it's the response ".. don't do this .." when a complicated problem is asked for help.
I think an experienced developers will answer :
" An idea to resolve your problem is :..........."
"But for these reasons..... it's better to not implement it ".
|
|
|
|
|
I'm not a very experienced developer and I haven't read the whole Thread ...
So I don't know if my answer is still given ...
When I read the first postings in this Thread my idea was :
You take your contents, which should be deleted out of your database and put is in an new one, which contains only this deleted things.
Now, if you want to recover it, you only have to chose the entry of the "deleted"-database and put it back to the "work"-database.
This "deleted"-database is only controlled by the application and could not directly accessed by the user.
|
|
|
|
|
This method have the problem with relationship.
I have explained in my earlier post :
Let suppose a record that have Childs , but this record itself is a child of another record.
If this record is deleted with its Childs , when I put on the other database , I will get an error because the parent of this record is not deleted , and will not exist on other database.
I'm thinking to get a identical table without the relationships , but I'm still testing this idea.
|
|
|
|
|
I think, you have to manage it like a class or a collection / List (of T).
If you "delete" an entry it isn't enough to store the data to a new Destination. You also have to memorize from where the data comes (and perhaps to whom the data belongs).
|
|
|
|
|
yes but as I said keeping the relationship inside the other database it's not possible. So I have to find another way to identify the parent of a deleted record. Maybe I can put another column to each table on the other database , and when a record is deleted , I can put on this column the parent's table name before saving to other database. ???
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
