Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
I have some design requirements that are not supported by Entity Framework, but are easily met by a simple SQL Query.
Essentially I need to do an insert that sets an Identity value.
Are there drawbacks to making a sproc that does my insert and then having EF call that sproc?
Are there caching concerns I need to be worried about? (Because I will be updating data “behind EF’s back”.)
Are there concurrency issues?
Anything else I need to be worried about?
If you don’t keep around your db context, i.e. you dispose it after every unit of work this should work just fine (this covers most web scenarios) – unless you concurrently operate on the same table – if that is the case you might want to use a lock to synchronize the SQL and the EF queries or catch
OptimisticConcurrencyExceptionthrown by EF.If you do keep a context around on the other hand make sure that you refresh it with
RefreshMode.StoreWins.Also see “Saving Changes and Managing Concurrency”