Change to LINQ to SQL EntitySet Member Doesn't Mark Root Object Dirty - by Roger Jennings

Status : 

  By Design<br /><br />
		The product team believes this item works according to its intended design.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.


3
0
Sign in
to vote
ID 305828 Comments
Status Closed Workarounds
Type Bug Repros 1
Opened 10/19/2007 12:49:59 PM
Access Restriction Public

Description

In a LINQ to SQL test harness with DataGridViews bound through a BindingSource to a DataContext with, for this example, a Northwind Customer entity and its eager-loaded Orders and Order_Details entity sets, making a change to a Customer (root) member's value marks the object dirty (i.e., it returns an object to the ctx.GetChanges<Customer>() method.)

Changing the value of a member of Orders or Order_Details entity sets in the corresponding DataGridView controls doesn't set the object dirty (i.e., the List<Customer> returned by the ctx.GetChanges<Customer>() method has a .Count of 0.

The workaround for this problem is a hack to change a Customer field value by, for example, adding a space to Customer.ContactName, then removing it in the WCF service. However, the issue isn't specific to SOA.

(This problem doesn't appear to be identical to that of https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=295116)

For more background on the problem, see the "Adding Missing Orders and Order_Details EntitySets to Original Values" topic of http://oakleafblog.blogspot.com/2007/10/linq-to-sql-has-no-multi-tier-story.html.
Sign in to post a comment.
Posted by Microsoft on 10/23/2007 at 7:14 PM
Thanks for reporting this issue you've encountered with Visual Studio 2008!

We've reproduced the issue you've submitted, but only before you press Enter on that row.

Each time a letter is added or removed from a column value, the CurrentCellDirtyStateChanged event is triggered, but the value returned by DataContext.GetChangeSet.Count is still 0. When this modification is actually committed by hitting Enter, the event is triggered again, but the DataContext.GetChangeSet.Count is now 1.

We therefore believe the behavior you experienced is By Design, but if the Count is still not 1 for you after hitting Enter, please reactivate this bug and let us know!

Thanks!

Alex Turner
Program Manager
Visual C#