4 ms·

For anyone that might not be familiar, Entity Framework is an ORM (object-relational mapper). The "blessed" way of doing an update is to retrieve an object from

For anyone that might not be familiar, Entity Framework is an ORM (object-relational mapper). The "blessed" way of doing an update is to retrieve an object from your context, change its properties, and call SaveChanges on the context. Yes, this can be terribly inefficient, particularly if you're trying to update many rows at once. But it works okay for single-row updates in a CRUD app at the expense of having to run the SELECT first plus all the reflection and change tracking. If you want to do fast, single-call updates without first doing a SELECT, or updates on just a few of the row's columns, since that can't easily be done with tracked objects, you're swimming upstream against what ORMs are designed to do and so your best option is to get out of ORM land and do a SQL query. Using context.Database.SqlQuery() or another library for these purposes like Dapper to parameterize your queries via reflection could help here.

smt88 9y ago
> The "blessed" way of doing an update is to retrieve an object from your context, change its properties, and call SaveChanges on the context. Yes, we know. As I said, we had multiple people who had been using .NET and EF for years. > Yes, this can be terribly inefficient I wasn't talking about efficiency. We're not at a stage where we're optimizing our queries. We just want code that works and is inexpensive to maintain. In this case, we just wanted EF to work at all. We never figured out why it wouldn't work. We got a weird, opaque error message. Our code was laughably simple: create the context, update a row, SaveChanges. That's it.
- paulirwin 9y ago
  Just trying to constructively help the community and build the body of knowledge around EF. I'd be interested in seeing example code to reproduce your issue, and I'd be happy to look into it. If there is a case where EF errors updating records, it would be good to help people know what to avoid or how to work around it, or possibly even submit a fix to the project. I've never seen a scenario that you're describing in my years with EF so it intrigues me. If you can make a gist or something that would be awesome. Or at least the error message as you described. I assume it was something like "An error occurred updating the entities", in which case the error message(s) from InnerException would be needed to diagnose. My most likely paths of diagnosing that issue would be to make sure the object is properly tracked in the context, ensure there aren't data type issues (i.e. having a System.DateTime value be default(DateTime) for a SQL datetime column that is out of range), make sure it isn't trying to update a computed/identity column, look for special SQL data types (geospatial, XML), if validation is turned on at the context level ensure the properties validate against the DataAnnotations, etc.
robodale 9y ago
I wish I could circle this response and write EVERYONE READ THIS. Agree with you 100%
Flott 9y ago
IF you have the primary key of the entity that you want to update, EF allow you to attach it to the context without querying the database. After attaching it to the context, you can set the new values, mark them as modified and (finally!) call SaveChanges. --- I do agree with you though! Dealing with it's limitations and edge case mean, sooner or later, falling back to SQL. EF is (imho) very hard to master and very easy to use "badly".
- deleted 9y ago
  [deleted]
teh_klev 9y ago
> Dapper This is all I use now, it's fast and lightweight, works with MSSQL and MySQL and I'm not averse to getting down and dirty with dynamic objects instead of having to define POCO's upfront. It's a hugely productive tool for me. I also don't mind writing raw SQL statements and I don't need to worry about having to abstract away the DB because these apps are targeted for specific DB products. Before Dapper when I went in search of ORM's for .NET I tried NHibernate, but too much config ceremony. Then I had a short dalliance with LINQ to SQL, it wasn't terrible, but it was a bit of a pain to work with legacy DB stuff, same with backing in new table columns/changes (sure I could edit the .dbml files directly then regen the .designer.cs, but meh). I had a look at EF 4.x but at the time its support for enums was non-existent (it took until 5.0's release in 2012) and that was a deal breaker. It was also just too much of a monster and got in the way, and I found myself more often tha not executing SQL directly via the data context. So yes, Dapper, thank you Mark Gravell, Sam Saffron and Nick Craver for with wonderful tool.

smt88 9y ago

> The "blessed" way of doing an update is to retrieve an object from your context, change its properties, and call SaveChanges on the context. Yes, we know. As I said, we had multiple people who had been using .NET and EF for years. > Yes, this can be terribly inefficient I wasn't talking about efficiency. We're not at a stage where we're optimizing our queries. We just want code that works and is inexpensive to maintain. In this case, we just wanted EF to work at all. We never figured out why it wouldn't work. We got a weird, opaque error message. Our code was laughably simple: create the context, update a row, SaveChanges. That's it.

paulirwin 9y ago
Just trying to constructively help the community and build the body of knowledge around EF. I'd be interested in seeing example code to reproduce your issue, and I'd be happy to look into it. If there is a case where EF errors updating records, it would be good to help people know what to avoid or how to work around it, or possibly even submit a fix to the project. I've never seen a scenario that you're describing in my years with EF so it intrigues me. If you can make a gist or something that would be awesome. Or at least the error message as you described. I assume it was something like "An error occurred updating the entities", in which case the error message(s) from InnerException would be needed to diagnose. My most likely paths of diagnosing that issue would be to make sure the object is properly tracked in the context, ensure there aren't data type issues (i.e. having a System.DateTime value be default(DateTime) for a SQL datetime column that is out of range), make sure it isn't trying to update a computed/identity column, look for special SQL data types (geospatial, XML), if validation is turned on at the context level ensure the properties validate against the DataAnnotations, etc.

robodale 9y ago

I wish I could circle this response and write EVERYONE READ THIS. Agree with you 100%

Flott 9y ago

IF you have the primary key of the entity that you want to update, EF allow you to attach it to the context without querying the database. After attaching it to the context, you can set the new values, mark them as modified and (finally!) call SaveChanges. --- I do agree with you though! Dealing with it's limitations and edge case mean, sooner or later, falling back to SQL. EF is (imho) very hard to master and very easy to use "badly".

deleted 9y ago
[deleted]

teh_klev 9y ago

> Dapper This is all I use now, it's fast and lightweight, works with MSSQL and MySQL and I'm not averse to getting down and dirty with dynamic objects instead of having to define POCO's upfront. It's a hugely productive tool for me. I also don't mind writing raw SQL statements and I don't need to worry about having to abstract away the DB because these apps are targeted for specific DB products. Before Dapper when I went in search of ORM's for .NET I tried NHibernate, but too much config ceremony. Then I had a short dalliance with LINQ to SQL, it wasn't terrible, but it was a bit of a pain to work with legacy DB stuff, same with backing in new table columns/changes (sure I could edit the .dbml files directly then regen the .designer.cs, but meh). I had a look at EF 4.x but at the time its support for enums was non-existent (it took until 5.0's release in 2012) and that was a deal breaker. It was also just too much of a monster and got in the way, and I found myself more often tha not executing SQL directly via the data context. So yes, Dapper, thank you Mark Gravell, Sam Saffron and Nick Craver for with wonderful tool.