locked
EF adding new entities twice? RRS feed

  • Question

  • I'm having a really hard time with an EF issue - been looking at it for several days now and was wondering if anyone has seen anything similar. The solution in question is a Silverlight application that's pretty much a glorified calendar. When viewing a given month, all necessary entities for that month are loaded into the context. For the most part everything works fine, but there's one scenario that's driving me nuts.

    When you view month, there are leading and trailing days that are viewable in the calendar. For instance, when viewing May 2012, the first week that displays is 4/29 - 5/5. Obviously, this same week is the last viewable week in April. "Tasks" are the main entity that we work with - they are basically custom appointments in the calendar. If the user creates a new Task in that first week, scrolls back to the previous month without doing anything and then scrolls to the original month and attmepts to create another Task, the behavior is almost like the Task has been loaded into the context twice. I get an exception every time I try to set one of the navigation properties of the new Task. These exceptions originate in the auto-generated navigation property setters; basically when the framework tries to add the new Task to the nav property's "Tasks" collection, it throws an InvalidOperationException saying that an entity with the same identity (0) already exists in the EntitySet.

    Some more information:

    • When I check the Tasks collection in the nav property setters before the first entity is saved, it's empty. When I check it before the attempt to save the second entity, the first Task is in there twice.
    • I've checked the Tasks collection in the context after changing months both times. It only contains the one Task.
    • This ONLY happens with Tasks that show up in multiple months. Using the example above (May 2012), if the initial Task is created later on in May - late enough so that it won't also display when viewing April - everything is fine.
    • I've tried clearing all of the Tasks out of the context when changing months to no avail. That said, the application is currently designed to hold onto all      unique entities as more and more months of data are loaded. I guess perhaps this is resulting in unwanted entities hanging around in the context but I simply cannot pin it down. I've tried all sorts of thing swith clearing particular entity collections on the context. I even tried just removing the nav properties in question from the model altogether, as they were automatcally generated when I imported the database and I actually have no use for them. When I did that it just postponed the exception until the Task was added to the context's Task collection during the save operation. In that situation it threw the same exception despite the fact that there was no Task in there with an ID of 0. Almost like it was trying to add it twice.

    I know it's hard to know what I'm talking about without viewing the actual solution but if anyone has seen any behavior like this maybe it could lead me down the right path. Basically, it seems like somewhere/somehow it's trying to add Tasks and their child properties to their respective collections twice and I can't figure out why.

    Wednesday, May 30, 2012 10:09 PM

All replies

  • Could you please post some code? So many words without code are difficulty to understand.

    Go go Doraemon!

    Monday, June 4, 2012 6:11 AM
  • Hi Kwame Johnson,

    Based on this issue, I think the root cause is related to Silverlight. After chaning the month, you didn't explicitly assign a navigation property to the entity, but the exception you mentioned only will appears when an entity has already tracked by the context, and we want to insert agian. So the behavior may caused by the Silverlight control, when you change the month, there're some events may be fired to lead this error.

    Best Regards


    Allen Li [MSFT]
    MSDN Community Support | Feedback to us

    Wednesday, June 20, 2012 5:42 AM