Home > Mobile >  Why is this unused line breaking Entity Framework?
Why is this unused line breaking Entity Framework?

Time:10-12

I am updating some existing code of a former colleague and have a strange issue where an unused line is causing an error with EntityFramework. If I comment out the code tagged with //This Line! everything works.

foreach (Place item in ListOfPlaces)
{
    //This line!
    List<Place> PlacesList = context.Places.Where(x => x.PlaceNumberID == item.PlaceNumberID).ToList();

    long PlaceId = context.Places.Where(x => x.PlaceNumberID == item.PlaceNumberID).Select(x => x.PlaceId).FirstOrDefault();

    if (PlaceId != 0)
    {
        item.ID = PlaceId;
        context.Places.Attach(item);
        context.Entry(item).State = System.Data.Entity.EntityState.Modified;
    }
}

If I include it, I get the error below on the Attach(item) line.

Attaching an entity of type 'Place' failed because another entity of the same type already has the same primary key value. This can happen when using the 'Attach' method or setting the state of an entity to 'Unchanged' or 'Modified' if any entities in the graph have conflicting key values. This may be because some entities are new and have not yet received database-generated key values. In this case use the 'Add' method or the 'Added' entity state to track the graph and then set the state of non-new entities to 'Unchanged' or 'Modified' as appropriate.

I know how to fix this from a code point of view (remove the line!), but I can't work out why its breaking the application if somebody could kindly explain please.

CodePudding user response:

Looks to me like the line causes the download of some place with ID N - see the ToList on the end? It will trigger the query to run and download data. EF creates objects from every row it receives

Later you try to create another object with the same primary key value and attach it to the context, but the context already knows about some object with ID 123 (for example) so you get an error when you try and associate another - if EF allowed both into its tracking memory it wouldn't know which one was the true authority of record that should be saved back to the db

Your interim query doesn't cause the problem, I believe, because it doesn't trigger the download of an entire entity, seeing as it just retrieves an ID

If you're trying to implement upsert style behavior, you should attempt to download an entity with ID x using some XOrDefault or Find, and if it results in null/default then create and add a new entity (you don't need to attach)

CodePudding user response:

That entire loop makes no sense. You repeat the same twice. And as soon as you select one of the items, EF marks it as a tracked. And you can't update using another item, before the first one will be untracked or you can use the tracked item.

Try this code

foreach (Place item in ListOfPlaces)
{
 var placesList = context.Places.Where(x => x.PlaceNumberID == item.PlaceNumberID).ToList();

 if(placesList!=null && placesList.Count ==1)  
{
  
 var existedPlace = placesList.FirstOrDefault();
    context.Entry(existedPlace).CurrentValues.SetValues(item);
}

}
context.SaveChanges();
  • Related