30 aprilie 2008 17:06
Is there a way to cancel changes in LINQ to SQL *WITHOUT* requerying all of the data?
Here is what I am doing:
1) I collect the list of customers using a stored proc and called ExecuteQuery
There could be as many as 2,000 customers … but I expect my performance will be OK.
2) I display the customers in a list and allow the user to pick individual customers to edit (one at a time).
3) When the user picks a customer … a dialog comes up with the customer details. The user then needs to OK or Cancel.
4) I can handle OK just fine using SubmitChanges.
I cannot figure out how to do Cancel without reloading all 2,000 customers.
Do anyone know of a way to handle the cancel operation with this?
The documentation says that Linq makes a copy of the object for the edit operation. I would think that there would be a way to toss out the copy and restore the original….
Thanks for any tips ...
1 mai 2008 16:47
The DataContext is a single unit of work; you discard the entities loaded into the context by creating a new one.
Alternatively, you can pick and choose some subset of fields from the Customer data that you need to display, and then subsequently load the user-selected Customer entity in its entirety.
1 mai 2008 20:00
So you are suggesting that I load the customer list with partial customer data? And then re-get the customer from the database when it is selected for update using a separate DataContext?
This does not match well with the current way I work with my business objects....
6 mai 2008 01:11
So what I understand is you update your entiy when the OK button is clicked, so why you just dont update your object in the context if OK is not clicked ? If you dont do any changes in the context then you wouldnt need to roll back.
May be if you can provide a code sample, and some info about the manner you work it would be more helpful - is it winapp or web, are you working connected or disconnected to data context ?
6 mai 2008 01:42
My application is a Windows application.
There would be no problem if the user did not change anything.
The problem occurs when the user *does* change data in the dialog ... but then hits Cancel instead of OK. Since the instance of the object associated with the dialog is the same object on the list ... the list is updated with the changes even if the user hits cancel.
Since I originally wrote this ... I found two different ways to handle it:
1) If you are *not* using stored procedures, you can use the Refresh option that takes a specific instance. It will call the database and refresh the instance without refreshing all of the data in the list.
2) If you *are* using stored procudures, you have to clear the DataContext and create a new one.
#2 implies that you *must* save each change as it occurs. Otherwise a Cancel will cancel *all* prior changes.
7 mai 2008 18:56
An alternative to #2 is to use the GetOriginalEntityState and then copy from that to the original object to "undo" the user's changes.