0

When using EF code first, is there a way to tell SQL Server to assign SYSUTCDATETIME() to a table column that corresponds to a DateTime property in the entity class I'm saving to the database.

If not, then how to solve the issue of having your C# code running on a server farm, where farm nodes can have slightly different system time. As a result, if e.g. Node1 is slightly ahead of Node2 and makes some database change slightly before Node2, the timestamp of the change made by Node1 can be greater than the timestamp of the change made by Node2, even though the actual change happened earlier.

Andrew
  • 1,139
  • 1
  • 12
  • 27
  • So what is the problem? – DavidG Jul 19 '17 at 11:26
  • Possible duplicate of [Possible to default DateTime field to GETDATE() with Entity Framework Migrations?](https://stackoverflow.com/questions/8594431/possible-to-default-datetime-field-to-getdate-with-entity-framework-migrations) – DavidG Jul 19 '17 at 11:36
  • Thanks @DavidG, the link you provided seems to be only covering inserting new records. How do I do this for updates as well? – Andrew Jul 19 '17 at 14:47
  • There isn't even a way to do that in SQL Server directly without a trigger. What exactly do you mean? – DavidG Jul 19 '17 at 14:49
  • @DavidG The problem is that if I insert to table A and then use the ID of the new record to update an existing record in table B, CreateDate in A can be later than the LastModified date in B. So I just used an ID from A in B before that ID appeared in A. This can mess up some reporting. – Andrew Jul 19 '17 at 14:52
  • This is why you shouldn't be using the last created ID *ever*. Instead, return the ID when you create it - EF does this for you automatically. – DavidG Jul 19 '17 at 14:54
  • "There isn't even a way to do that in SQL Server directly without a trigger." - in SQL server directly I have always been using stored procs, so I had full control over what the application was writing to the DB and how. But on this project I have to use EF... – Andrew Jul 19 '17 at 14:55
  • "This is why you shouldn't be using the last created ID ever. Instead, return the ID when you create it" - sorry I did not get that. So I insert to A, get the ID back. Now I use the ID to update B, but the update operation might go through another server in the farm. – Andrew Jul 19 '17 at 14:59
  • So don't used the ID to retrieve the entity. If server B is updating a record, then it must have some unique information about the record that you can use to lookup the actual ID to use. If that's not the case, then your app isn't suitable to be used in a multi server environment without some rework. – DavidG Jul 19 '17 at 15:03
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/149621/discussion-between-andrew-and-davidg). – Andrew Jul 19 '17 at 15:04
  • "So don't used the ID to retrieve the entity." - I'm not. I insert to A and get A_ID back. Then I already have a record in B, and I already know it's ID being B_ID. I update column A_ID in table B, in the row with ID = B_ID. – Andrew Jul 19 '17 at 23:57

0 Answers0