Take the 2-minute tour ×

Is there any way I can tell EF to not worry about the number of rows a DELETE or UPDATE do or don't do?

I'm trying to delete a row from the database, but because the row doesn't exist, EF throws an exception: DbUpdateConcurrencyException .. saying 0 rows were affected. This is right -> no rows were deleted. But that's totally fine .. cause there's no data.

I don't really want to do a round-trip to the DB to see if that row exists .. and if so .. then try and delete it.

If i try and swallow the exception in a try / catch block, then the rest of the items to be deleted do NOT get sent to the db, when I try to SaveChanges() ... which is bad.


Delete(new Foo(1));
Delete(new Foo(2));
Delete(new Foo(3));
SaveChanges(); // <-- Throws the exception.

// DB Trace : DELETE FROM Foo WHERE Id = 1;

and thats it.. there's no trace showing record 2 or 3 trying to get deleted .. because the exception stops everything :(

Any ideas?


How does Delete work? Here's the code... (simplified and strongly typed)

public void Delete(Foo foo)
    if (foo == null)
        throw new ArgumentNullException("foo");

    Foo attachedEntity = Context.Set<Foo>().Local.FirstOrDefault(x => x.Id > 0);

    if (attachedEntity != null)
        // Entity already in object graph - remove entity.
        // Entity not in object graph, attach and set EntityState to Deleted.
        Context.Entry(foo).State = EntityState.Deleted;
share|improve this question
How does Delete function work? –  LukLed Feb 17 '11 at 2:03
@LukLed - edited OP with extra code. –  Pure.Krome Feb 17 '11 at 2:13
I understand that these deletes are a part of bigger operation and can't be made independently? –  LukLed Feb 17 '11 at 2:30
Even if they were made independently, the same problem exists -> trying to delete a DETACHED object which doesn't doesn't exist in the DB. I don't care if the row exists or not - > just try and remove it. If it's not there, no probs. if so, then delete. Done. /me slaps EF. –  Pure.Krome Feb 17 '11 at 2:57
Ever find a solution for this? It's a major pain when performing multiple operations in a single SaveChanges call. –  ShadowChaser May 31 '12 at 19:10
add comment

2 Answers

I think the behavior of EF is correct - simply you must execute commands only for objects which are present in DB. It is not for scenarios like: "I will try it and we will see...". If you can't be sure that object exists in DB and you don't want to do round trip (which I think is the best idea because deleting detached object can have several other pitfalls especially if object participates in independent associations) you should use DbContext.Database.SqlCommand and run store procedure.

The correct way to handle DbUpdateConcurrencyException is described here => After each exception you should resolve confilicts (in your case it means remove problematic entity from DbContext) and execute SaveChanges again.

share|improve this answer
Ah :) Earlier today I was exerimenting with using a try/catch around the Context.SaveChanges() to handle any DbUpdateConcurrencyException exceptions .. but all I was doing was a Refresh() .. then SaveChanges() again .. which of course didn't work (threw the same error). Can u update you answer to include HOW u remove the offending entity from the Context, please? –  Pure.Krome Feb 17 '11 at 10:23
@Pure.Krome: I would try to use ChangeTracker and set entity state to Detached. –  Ladislav Mrnka Feb 18 '11 at 9:42
can u please elaborate on your previous comment, please? –  Pure.Krome Feb 22 '11 at 7:03
@Pure.Krome: Try to use exception.GetEntry(dbContext).State = EntityState.Detached; Where exception is catched DbUpdateConcurrencyException. If this doesn't work you will simply have to check that entity exists before you mark it as deleted. –  Ladislav Mrnka Feb 22 '11 at 9:11
I disagree with the answer, the behavior of EF is not correct. Think of it this way - User A does SELECT, exists. User B does exist, exists. User A deletes, succeeds. User B deletes, fails with exception. In both cases the result should be the same - we're deleting the record. Sure, there's a conflict, but the result is the same - a deleted row. There's nothing to resolve. "Checking to see if it exists first" doesn't work - it's a race condition. Can't lock on reads in all cases, in our case we're using MySQL Cluster - no read locks. –  ShadowChaser May 31 '12 at 18:58
add comment

You can in fact ignore these kinds of issues by setting:

db.Configuration.ValidateOnSaveEnabled = false;

Where db is the DbContext instance.

Obviously you should know what you're doing when you do this, but then again, most approaches to updating a database that are not EF don't have any change tracking/validation and just issue update/insert/delete to the database naively without checking anything first, so you're basically just telling EF to behave more like that.

share|improve this answer
Are you sure? ValidateOnSaveEnabled controls data annotation validation, not concurrency. My understanding is that (as of EF 4.3) there's no way to suppress the DbUpdateConcurrencyValidation for deletes. –  ShadowChaser Sep 12 '12 at 18:26
I tested the above claim before posting; I created 2 DbContexts, used one to fetch an object, another to fetch, change, and save an object, and then finally attempted to change and save on the first one. I got an Exception; changed the above setting to false, ran again, no Exception. In addition, have you checked the documentation? It refers to validating the entity, not the schema: msdn.microsoft.com/en-us/library/… –  Chris Moschini Sep 13 '12 at 19:34
add comment

Your Answer


