Continuing traking after sync

Sep 10, 2010 at 11:45 AM

Hi Matt,

First and foremost, I have to say your way of making L2SQL able to sustain disconnected scenarii is great and is the only thing that makes me change my whole Data Access layer.

I had a question though for a special context:

- I have a detached object scenario in a Web application (an entity tree is updated through postbacks...).

- At some point, I have to resynchronize the entities with the database.

- I am constrained to log the modifications made to this tree but these modification have to be hooked to this tree before update.

- It has to be done in a transactional way.

In order to do so, I use the synchronization you provide to update the datacontext and check the modification from the data context tracking system. I then add the snew entity containing the modifications declaration to the tree and resynchronize the whole tree to a new datacontext.

First time I tried this : I synchronized my tree against a new datacontext, I got the modification list, added it to the main tree, and tried another synchronization on another new datacontext. However, the first synchronization call had cleared the modified state on the tree and I was not able to get the datacontext modified again.

In your codein this method:


public void SynchroniseWithDataContext(DataContext targetDataContext, bool cascadeDelete)

There is a line



which basically loses the tracking whenever the synchronization is done.

Once commented I managed to make my scenario work, provided that when I submit my datacontext to the database, I actually call the



Method on the tree.

-> So is this a normal behaviour as I may not use your code as intended (I don't actually synchronize everytime to submit the datacontext and this line breaks the tracking as well as synchronizing, disabling the ability to resynchronize later).

Feel free to ask for infomation.



Sep 11, 2010 at 11:27 PM

Hi Eric,

I think I have this right, you want to:

- Sync the changes with the data context 1 (but do not submit changes)

- Find out which records are modified from the data context, add representations of these modifications to the same entity tree

- Sync the changes with the data context 2 and submit changes

I think this should work except it sounds like you are doing synchronization with two different data contexts?  Is there are reason why you don't just synchronize with the same data context?


Regardless, here's some ideas:

1. Use the entity root to return you a list of modification instead of attaching to the datacontext first to identify them

For Example: 

from x in customer.ToEntityTree()

where x.LINQEntityState == EntityState.Modified;

2. If you must do it the way you've been doing it, you can take a snapshot of entity tree (using the Serizalization methods), apply that to the first data context, identify the modifications, and then add the list of modifications to the original entity tree, synchronize that and submit changes.





Sep 13, 2010 at 10:57 AM
Edited Sep 17, 2010 at 9:18 AM

Hi Matt,


Thanks a lot for your reply.

First, I reply to your interrogations:

The reason why is because I have to check once if I have modification, and if some criterion are met (i.e some modifications are done on certain properties), I have to ask the user some additional information before actually persisting. It’s a business requirement.

I then have to rerun the synchronization to make the actual modification on a second datacontext (the first one is lost). Even then, I don’t necessarily have to persist the map, only the modification list might have to be persisted : again, business reqs..


About your hints now:

1. I already use this to know if there is a modification. The fact is that I also need to check every modification on certain properties (not only entities). This functionality is given by the L2SQL framework, but obviously, only for synchronized datacontexts. I didn’t find a way to check for props modifs in an entity (if not checking actual data against old data foreach prop of every entity);

2. I never thought about using clones to do this. This might clearly do the trick. Using copies of the entity tree in order not to alter the one modified by the user until the last moment is a great idea.


One last point, as I have modified your code about the logic of changing the state automatically on sync, it works for my scenario.


I’ll keep you tuned if I manage to modify my code according to your second idea.

Have a nice day.




Edit :

Hi Matt.

I changed my code in order to check changes by synchronizing a copy (thanks for your serialization tips, works like a charm) with my data contexts. It avoid the problem of losing the modification tracking when checking for changes. Everything is working fine. Thanks for the hints in your message and thanks for taking time to respond.