We Keep Coding

The instance of entity type cannot be tracked because another instance with the same key value for is already being tracked [closed]

Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 23 days ago.
The community is reviewing whether to reopen this question as of 12 days ago.
Improve this question
The instance of entity type 'AssegnazioneLotto' cannot be tracked
because another instance with the same key value for
{'Id_AssegnazioneLotto'} is already being tracked.
When attaching existing entities, ensure that only one entity instance
with a given key value is attached.
Consider using 'DbContextOptionsBuilder.EnableSensitiveDataLogging'
to see the conflicting key values.
I encounter this error when we call data from a table and update it.
I solved it by calling a view which calls the table.
Why does this happen?
How can I solve without creating additional views?

The simplest answer: Don't pass entities around outside of the scope they were read. Pass view models (POCO objects rather than entities) and fetch entities on update to copy expected values across.
The complex answer is that when updating entity references, all entity references including child collections and many-to-1 references, you need to check if the DbContext is tracking a matching reference, and either replace the references with the tracked entity, or tell the DbContext to dump the tracked reference before attaching.
For example, an update method that accepts a detached or deserialized "entity". What works sometimes, but then craps other times:
public void UpdateOrder(Order order)
{
context.Update(order);
// OR
context.Attach(order);
context.Entry(order).State = EntityState.Modified;
context.SaveChanges();
}
Looks simple and clean, but craps out when the DbContext instance might already be tracking a matching Order instance. When it is, you get that exception.
The safety check:
public void UpdateOrder(Order order)
{
var existingOrder = context.Orders.Local.SingleOrDefault(o => o.OrderId == order.OrderId);
if (existingOrder != null)
context.Entry(existingOrder).State = EntityState.Detatched;
context.Update(order);
// OR
context.Attach(order);
context.Entry(order).State = EntityState.Modified;
context.SaveChanges();
}
That example checks the local tracking cache for a matching order and dumps any tracked instance. The key here is searching the .Local with the DbSet to search the local tracking cache, not hitting the DB.
Where this gets more complex is where Order contains other entity references like OrderLines, or a reference to a Customer, etc. When dealing with detached entities you need to check over the entire object graph for tracked references.
public void UpdateOrder(Order order)
{
var existingOrder = context.Orders.Local.SingleOrDefault(o => o.OrderId == order.OrderId);
if (existingOrder != null)
context.Entry(existingOrder).State = EntityState.Detatched;
var customer = context.Customers.Local.SingleOrDefault(c => c.CustomerId = order.Customer.CustomerId);
if (customer != null)
order.Customer = customer; // Replace our Customer reference with the tracked one.
else
context.Attach(order.Customer);
context.Update(order);
// OR
context.Attach(order);
context.Entry(order).State = EntityState.Modified;
context.SaveChanges();
}
As you can see, this starts to get complex and cumbersome pretty quick as you need to check every reference. Hence, it's simpler to avoid passing detached or serialized entities around. Using a View Model offers many benefits for performance and simplifying issues like this. Coupled with AutoMapper or a similar mapper that supports projection can make operations with view models very simple:
Selecting Orders:
var orders = context.Orders.Where(/* suitable conditions */)
.ProjectTo<OrderViewModel>(_mapperConfig)
.ToList();
Where _mapperConfig is an AutoMapper configuration that tells AutoMapper how to convert an Order into an OrderViewModel. This can follow conventions or optionally contain mapping rules to build a flattened view model for an Order and it's relative details. ProjectTo works with EF's IQueryable to build an SQL SELECT statement across the entity graph to return only the data needed to populate the view model. This is far more efficient than using Map which would require all related entities to be eager loaded.
When updating:
public void UpdateOrder(UpdateOrderViewModel orderVM)
{
var order = context.Orders.Single(o => o.OrderId == orderVM.OrderId);
if (orderVM.RowVersion != order.RowVersion)
throw new StaleDataException(); // placeholder to handle the situation where the data has changed since our view got the order details.
var mapper = _mapperConfig.CreateMapper();
mapper.Map(orderVM, order);
context.SaveChanges();
}
orderVM could be an OrderViewModel returned, but typically I would recommend packaging just the fields that can be updated into a dedicated view model. The "magic" is in the AutoMapper configuration which governs what fields get copied from the view model back into the entity. If can include child data such as OrderLines or such, in which case you would want to ensure those child entities are eager loaded /w .Include in your DB fetch. AutoMapper's Map method in this case is the variant that copies mapped values from a source to a destination, so values are copied across directly into the tracked entity instance. EF will build an SQL UPDATE statement based on what values actually charge rather than overwriting the entire record.
You can also use the same technique with detached entities to avoid your issue. The benefit of using AutoMapper is that you can configure which values can be legally copied over from the deserialized/detached entity provided into the real data:
public void UpdateOrder(Order updatedOrder)
{
var order = context.Orders.Single(o => o.OrderId == orderVM.OrderId);
if (updatedOrder.RowVersion != order.RowVersion)
throw new StaleDataException(); // placeholder to handle the situation where the data has changed since our view got the order details.
var mapper = _mapperConfig.CreateMapper();
mapper.Map(updatedOrder, order);
context.SaveChanges();
}
This ensures we only change what is allowed to change, and avoids the whole crapshoot of tracked references. In our mapper configuration we literally have an entry like:
cfg.CreateMap<Order, Order>(...)
which will hold explicit rules to ignore copying across fields and related entities we don't want copied across on an Update.
The downside of doing this is the overhead of sending entire entities and potentially their related entities across the wire back and forth, plus to be "safe" from tampering, a lot more effort needs to go into the mapper configuration or copying across allowed values explicitly.

I had the same issue with EF Core and Blazor Server. Switching the scope in the service collection to "Transient" and using a ServiceScopeFactory for the queries/updates did the trick. You'll see below I'm using the Blazor style dependency injection, but constructor injection will still work the same way for an IServiceScopeFactory
[Inject]
IServiceScopeFactory _serviceScopeFactory { get; set; }
private async Task UpdateItem(GridCommandEventArgs args)
{
var utilityItem = (EntityModelSample)args.Item;
using (var scope1 = _serviceScopeFactory.CreateScope())
{
var dbContext = scope1.ServiceProvider.GetService<SampleDbContext>();
dbContext.Update(utilityItem);
await dbContext.SaveChangesAsync();
}
LoadData();
}
In the startup code:
builder.Services.AddDbContext<InternalUtilitiesDbContext>(option => option.UseSqlServer(connectionString), ServiceLifetime.Transient);

this code fix your problems::
builder.Services.AddDbContext(option => option.UseSqlServer(connectionString), ServiceLifetime.Transient);
ServiceLifetime.Transient

Is this an EF Core bug or an I doing it wrong to update one entity?

I'm using Entity Framework Core together with the repository pattern. To help me out, I coded one base repository with the basic CRUD methods. The update method is as follows:
public void Update(TEntity entity)
{
var contextEntry = _context.Entry<TEntity>(entity);
if (contextEntry.State == EntityState.Dettached)
{
_context.Attach(entity);
}
contextEntry.State = EntityState.Modified;
_context.SaveChanges();
}
Given the BaseRepository class containing this method, I created one User repository inheriting from this
public class UserRepository : BaseRepository<User>, IUserRepository
{
}
And I've used this in the PUT method of one Web API coded with ASP.NET Core
[HttpPut("~/api/users/{id}")]
public IActionResult Put(int id, [FromBody] User user)
{
if (user == null || user.UserId != id)
{
return BadRequest();
}
userRepository.Update(user);
return new NoContentResult();
}
Now, when issuing a request, I get one error in the _context.Attach(entity) line. The exception says that it can't add the entity for tracking because there is already another entity with the same key being tracked.
When debugging I saw that contextEntry.State was set to Unchanged. Hence, it is obviously not equal to EntityState.Dettached. Still, the execution got inside the if statement and tried to attach the entity.
Something is quite wrong here. Is this a bug? Or am I doing something very wrong? I believe that I'm the one doing something very wrong with this update strategy, but I'm unsure about it. In that case, what is wrong with my approach?
EDIT: I updated the Update method to use just _context.Update(entity) and after _context.SaveChanges(). Still, the _context.Update(entity) throws one InvalidOperationException with this message:
Additional information: The instance of entity type 'User' cannot be tracked because another instance of this type with the same key is already being tracked. When adding new entities, for most key types a unique temporary key value will be created if no key is set (i.e. if the key property is assigned the default value for its type). If you are explicitly setting key values for new entities, ensure they do not collide with existing entities or temporary values generated for other new entities. When attaching existing entities, ensure that only one entity instance with a given key value is attached to the context.

You are getting same entity from database some where in the project that's why it give you error.
In Update method you just add the entity in the context that's why you get contextEntry.State Unchanged.
You can fix this problem in two ways.
You need to call the Detach method on same entity when you get it from database.
copy the values from entity which you received in Update method to the existing context entity and save that entity in database.

All the information is in the exception message... you already have another copy of the entity with that primary key attached.
I would recommend one of the following (preferred first):
Use a new Context for each action, don't have a long-lived repository/context
Use .Set<TEntity>.Find(object[] key) on your context using the Primary Key, in order to retrieve any entity you already have.
In your current update method, use the Set<TEntity>.Local.Find(..) to check if it already exists

Updating child properties in Entity Framework TPH

I'm new to inheritance with EF in C#/MVC, and I'm trying to update a subclass's navigation property but can't figure out how to do so. The subclass inherits from the parent class, obviously, and it has its own EF mapping specified. I have to update the DB using the parent type, otherwise nothing is pushed to the DB (no error is thrown though). Using the parent class, however, doesn't expose the child properties so I can't update them to even push to the DB.
What is the proper way to handle subclass-specific properties in EF?
This is more of a general question than one specific to my issue, but here's the code that doesn't work.
// get the existing task using the model posted from view,
// convert it to child class (GetTaskById returns parent class)
PETask task = _projectService.GetTaskById(model.Id).ConvertToET();
var proj = _projectService.GetById(model.ProjectId);
// error checking
if (ModelState.IsValid)
{
// use AutoMapper to convert the posted data to entity, passing task as
// a parameter to preserve proxies
task = model.ToEntity(task);
if (model.SOId.HasValue)
{
SalesOrder so = _salesOrderService.GetByOrderId(model.SOId.Value);
task.SalesOrderId = so.Id;
task.SalesOrder = so;
}
_projectService.Update(task);
// all information is correct, including a proxy for the SalesOrder property
// and the actual SalesOrderId, but the DB is not updated. no error is thrown.
}

The ObjectContext instance has been disposed when using entity in view

There were many related questions, but none solved my matter. My purpose here is generating a pdf using Razor PDF.
So I have a controller action, which contains;
var pdf = new PdfResult(null, "myView");
ViewBag.VrList = MyDbQuery.GetExpiredVL(DateTime.Today);
return pdf;
MyDbQuery is in a different solution which I'm using. And there I have this method:
public static List<VLEntity> GetExpiredVL(DateTime ReportDate)
{
using (MyDbContext db = new MyDbContext())
{
return db.VLEntity.Where(vl => vl.ValidTo.Month == ReportDate.Month && vl.ValidTo.Year == ReportDate.Year).ToList();
}
}
My view looks like:
#foreach (var vrRow in ViewBag.VrList)
{
#vrRow.VEntity.VssId
}
When I debug, I get:
System.ObjectDisposedException: The ObjectContext instance has been disposed and can no longer be used for operations that require a connection.
In similar questions i have found here says to use using statement. But you can see here I have already used that. I'm very new to ASP.NET and C# altogether and I'll be grateful if you can come up with a solution for this.

In this code:
#foreach (var vrRow in ViewBag.VrList)
{
#vrRow.VEntity.VssId
}
You're accessing the navigation property VEntity. If you don't disable lazy loading (which is enabled by default), this property isn't loaded from the database when querying, but only when accessing the property (through proxy generation).
In your data access method you do db.VLEntity.[..].ToList(), but that only materializes the VLEntitys returned from the query - not their navigation properties.
Because of the disconnected scenario (the action method in the controller runs first, then hands its data off to the view), the context is not accessible anymore where you access the navigation property.
For this, you need to explicitly load the navigation property (as you claim you did):
return db.VLEntity
.Include(v => v.VEntity)
.Where([..])
.ToList();
Now when the view accesses the VEntity properties of the list are also materialized, so your view doesn't have to access the database anymore.
You also say it worked before, but then you probably just didn't access any navigation properties.
Related: Best practises in MVC for not disposing the object context?, How to solve the error The ObjectContext instance has been disposed and can no longer be used for operations that require a connection.
Alternatives would be to keep the DbContext around longer (which you shouldn't want) and introducing a ViewModel that you map to in the controller.

winforms An entity object cannot be referenced by multiple instances of IEntityChangeTracker

I am getting this error when trying to add multiple properties.
public NewPropertyHelper(DataLayer.IAccrualRepository Repository) {
this.SaveAction = Properties => {
foreach (Property P in Properties)
{
Repository.Properties.AddObject(P);
Repository.SaveChanges();
}
};
}

From what I can gather, the line
Repository.Properties.AddObject(P);
is attempting to add the object P to the current repository, and since you got it from a different repository you'd need to remove it (or detach it) from the other repository first.
EDIT: So I am assuming that somewhere in Repository, there is a wrapped DataContext (or maybe Repository inherits your DataContext. When you get an object from a DataContext, the object is constantly references by a change tracker, which keeps track of what needs to be sent back to the database if you update that object. Because you don't want to double-count any objects, EF prevents you from attaching that object to more than one data context at a time. Before you can attach the object to a new data context, you need to detach it from the DataContext that is already tracking it.
To do that, you need to call the Detach method on the object and any objects that it references that are also tracked by EF. A good example of how to do that is here: http://www.codeproject.com/KB/linq/linq-to-sql-detach.aspx