|
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. ???
|
|
|
|
|
It smells like you have a weird kind of depandancy inside your database ...
|
|
|
|
|
Why is wired ?
Table 1 - Master records.
Table 2 - Child records for table1
Table 3 - Child records for table2.
If I delete a record from table2 with all the childs in table3.
The problem that I've described will happen.
|
|
|
|
|
Not "wired" - weird - that means a kind of crazy ...
Back to your question.
If an element of "Table2" represents "Table3" as datatable then you have to memorize the element WITH it's containing structure. I've never made this but I can't imagine, where the problem is.
If you cut it from the datatable then you have a List inside a List completly independant from the Content). The included List is an Object like a single element too.
|
|
|
|
|
Sorry , the problem is not for Table 2 and table3 , but with table1.
For example :
Table 1 ( ID=25 , Name=nm1 )
Table2 ( ID=4 , parentID=25 , name=nmtb2 ) ( foreign key - on parentID )
Table3 ( ID=50 , ParentID=4, name=nm3 ) (foreign key on ParentID )
Now if I delete the record with id=4 from table2 together with the child in table3 , when I try to put these on the other database , I get an error , because the record with id=25 that is the parent of the deleted record , doesn't exist on Table1 (on the other database) because is not deleted.
|
|
|
|
|
Only if he is paid. We're volunteers.
People will stop answering altogether if you dismiss each suggestion. We're trying to help, which you obvious do not like.
--edit
Ah , so if I pay you , you will change your opinion about this problem .
Confused |
No, but I'd be politer in telling you what can and cannot be done, and I'd be paid to correct your ignorance. Since I'm not paid for it, I'm going to say goodbye - that's how it works, once it becomes an annoyance, the help stops.
Good luck, you will need it.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
modified 29-Jun-15 5:20am.
|
|
|
|
|
Ah , so if I pay you , you will change your opinion about this problem .
|
|
|
|
|
So if I pay you , you will change the opinion about this question and you will give an idea ?
|
|
|
|
|
Regardless of how much you offer, the answer will be a no.
Simply because I don't want to.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
In my country , there's a Proverb :
" When the fox did not achieve to get the grapes , she said that they were undone "
Hope to understand. 
Before down vote this , first try to understand what does this mean
modified 29-Jun-15 6:16am.
|
|
|
|
|
Congratulations on your abuse vote.
Anything else, or do you want to drop the subject? Doesn't look like any of us will gain anything from it.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
I don't care.
I'm not here to collect votes.
Maybe you are.
And when you or your friends here have no more to do with a subject , you put a down vote.
Well , please put another , I will be happy . 
And I don't think that you or who down vote has understand the proverb.
|
|
|
|
|
I think the ignorant is you .
You have no idea how to resolve the problem , and to cover your ignorance , you just answer that this is not good to be done. 
|
|
|
|
|
 No insults please.
I don't think that Eddy doesn't know from what he speaks.
|
|
|
|
|
Was Eddy that insult me for the first. Read his post.
|
|
|
|
|
satc wrote: I think the ignorant is you .
Whatever you want, kid
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Yes pupil.
|
|
|
|
|
We've been telling you how to resolve the problem, over and over again. YOU refuse to listen to it because it doesn't fit what you envision.
Moving records to a second database is bullshit. It overcomplicates things greatly. That correct solution is to tag the records deleted but never execute a hard delete on them. That way it's really very easy to "undelete" them. You just change the delete flag on the record.
No scripts as this adds even more complexity and incompatibility when you change the database schema.
But hey, if you want to support this pain in the ass method you want to implement, and trust me, you WILL regret doing this, go right ahead.
I'm done here and on every other question you ever ask.
|
|
|
|
|
Quote: We've been telling you how to resolve the problem, over and over again. YOU refuse to listen to it because it doesn't fit what you envision.
Moving records to a second database is bullsh*t. It overcomplicates things greatly. That correct solution is to tag the records deleted but never execute a hard delete on them. That way it's really very easy to "undelete" them. You just change the delete flag on the record.
And I have confirmed that I have used your idea only for the "soft delete" level. for hard delete level this has no sense.Because I will keep on my database a lot's of records that probably for the most of them I never need again.
For this I'm trying to find a way for Hard delete - Recover.
For this , everyone says that it can be implemented but it's not a good thing to implement.
Well , regardless if a bad idea , just show the idea.
Quote: I'm done here and on every other question you ever ask.
Whatever you want , nobody is forced to answer a question whatever the reason he may have ( Doesn't want , doesn't know , want to look that he know but he doesn't know , it's difficult and he has no time to loose ......)
And , of course to show the power , instead of response , it's better a down vote
|
|
|
|
|
As others have said, the best way to handle the delete with Entity framework is to have a soft-delete column. Now, if your requirement to manage hard deletes is an absolute must, then you are going to have to get down and dirty at the database itself - there is no way you can manage this via Entity Framework because, apart from anything else, the hard delete might just happen with the user typing DELETE.... directly against the database.
Given the fact that you now know that you will need to do this at the database level, this suggests that the mechanism might well have to be something that can react to a SQL command at the database. This would indicate, to me at least, that the mechanism that you are looking for is to use a delete trigger (actually, you're going to want to build up a lot of triggers). Now, a trigger is an atomic operation that only acts on one table so you're going to have to be clever with the way you build your trigger "scaffolding" so that you can recreate disparate statements. There's no real fool-proof way of guaranteeing that you can recreate the records because the user can do things in a way that prevents this, but you could make a best-effort that helps achieve this.
|
|
|
|
|
Thank you !
I need to do this via Entity Framework.
So keeping another database where I put "hard deleted" records it seems a possible solution.
The only problem is that I can't keep the relationships for the reasons I've described above , so I'm testing a way to keep another database identical but without relationships. The problem that I have to resolve is when a user need to restore a deleted record , how can I know which is the parent of this record and which are its childs.
|
|
|
|
|
The "easiest" way is probably to change database and use Oracle Flashback[^] technology.
So, changing database is neither fun nor easy, but your other options are to use soft deletes, as has already been suggested by more experienced developers than me, or implementing your own solution.
Probably involving lots of triggers and transaction tables and I do not recommend it.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
