How to detach a LINQ-to-SQL data object from the DataContext's tracking mechanism?

Question

After asking this question, where I was informed of how the Table<T>.Attach() method works, I have another question.

How do you detach a LINQ-to-SQL data object from the DataContext's state tracking mechanism? Basically, I want to pull a record and change the data on the record. But, when I call SubmitChanges() on the same DataContext instance, I do not want the record to be updated unless I have explicitly called Attach(). How is this accomplished?

Solution 1

From this site explaining how to detach a linq object add this method to the object you want to detach:

public void Detach()
{
    GetType().GetMethod("Initialize", BindingFlags.Instance | BindingFlags.NonPublic).Invoke(this, null);
}

Solution 2

I strongly recommend that if you're going to use LINQ to SQL, you should change your design to accommodate LINQ to SQL's behavior of submitting changes on all attached modified entities. In my experience, attempting to work around this feature will only lead to pain.

Solution 3

Unfortunately, you cannot explicitly detach entities from previous DataContext, without serializing and deserializing the entities.

What you can do for your purpose is to create a copy of the object you pulled out of the DB and work with the copy. In this case your original object is untouched. When the time comes to update the DB, you can simply attach the copy to your DataContext.

Comments

[Kotheof]

I could be wrong, but I don't think this will work. If you pull an object on a context, clone it, and try to attach the clone to the same context the original was queried with, you'll get an error saying you can't attach an entity that is already on the context.

[smartcaveman]

+1, because in general this is great advice (and not just with LINQ to SQL). However, this doesn't actually answer the question.

[Andrei]

Well, you are right. it would depend on the solution, though it will work if the clone outlives the DataContext object.

[Andrei]

If not, then you can copy the values back into the original from the clone.

[Kirk Broadhurst]

This will yield a DuplicateKeyException with message Cannot add an entity with a key that is already in use.

[Damien]

That's why I said that any attached entities must be "requeried"

[Jordan Rieger]

I had to use this hack because I was using a custom-built caching library for LINQ to SQL entities, based on Pete Montgomery's blog post at petemontgomery.wordpress.com/2008/08/07/…. I had multiple threads trying to serialize the same cached entity, and the DataContractSerializer was triggering a walk through the entity members that caused simultaneous access of the DataContext, which is not thread safe. So I was properly isolating my DataContext and not submitting changes, but I still got burned. This manual Detach method was the simplest fix.

[Protector one]

Big caveat: this requires that you're using SQLMetal for generating model objects, and use the /serialization option when doing so: docs.microsoft.com/en-us/dotnet/framework/data/adonet/sql/li‌​nq/…