Sunday, July 20, 2008 9:13 PMHello,
I'm trying to save object containing collection of child objects. As long as it is on the same datacontext as for selecting, everything is ok. The problem is that collection of child objects doesn't update when I'm attaching this object to a different datacontext and call SubmitChanges(), it saves only properties of the parent object. Anyone knows a good solution? I don't want to synchronize this collection manually or keep datacontext in memory.
Monday, July 21, 2008 4:30 PM
Mixing entities from different DataContext instances is not a recommended or supported scenario.
Monday, July 21, 2008 5:01 PM
It's Win forms app, so should I keep DataContext between displaying data to the user and clicking "Save" button? Or on saving should I take original object from the database and assign changed values? Or is there any other way of doing it?
It looks like in many cases it's not possible to update data in any recommended way.
Monday, July 21, 2008 5:16 PM
It is OK to keep the DataContext alive if the set of operations you perform are logically related (i.e., they are a unit of work) -- for example, you query some data, display it, let the user make some changes, and then click the Save button. This is all one single unit of work, so you can use the same DataContext for the entire set of operations.
Friday, March 09, 2012 7:37 PM
How do you keep the context alive if you are using a WCF service reference to communicate between the UI and Data Access Layer? I am having the same issue. Here is my update function in a separate project from the winForm.
Public Function UpdateContact(ByVal UpdatedContact As Contacts) As Contacts
Dim key = TalentContext.CreateEntityKey("Contacts", UpdatedContact)
Dim OriginalContact As Contacts = Nothing
If TalentContext.TryGetObjectByKey(key, OriginalContact) Then
The UpdatedContact contains the changes made to the parent Contacts object and the child Addresses object.