在实体框架中,使用存储过程进行乐观并发的表更新操作。我一直无法使其正常工作,而不修改现有的更新存储过程。我正在尝试确定是否有一种方法可以映射我的现有存储过程,以便在没有更新任何行时出现并发异常。
一些背景信息:
一些背景信息:
- I've mapped the update stored procedure (including the timestamp) column in my .edmx file
My existing stored procedure looks like the following (the actual table names and columns are obviously omitted):
UPDATE Table SET Column = @Column1, Column2 = @Column2 .... WHERE PK = @PK AND Timestamp = @Timestamp SELECT PK, Column1, Column2, ....., Timestamp FROM Table WHERE PK = @PK
In the event that the update fails (due to a timestamp mismatch) the select portion of the stored procedure will still return a row.
UPDATE Table SET Column = @Column1, Column2 = @Column2 ....
WHERE PK = @PK AND Timestamp = @Timestamp
IF @@ROWCOUNT > 0
SELECT PK, Column1, Column2, ....., Timestamp
FROM Table WHERE PK = @PK
然后一切按预期进行,并发错误就会发生。
或者,如果我使存储过程返回一个输出参数,并将该输出参数映射到 Entity Framework 的 .edmx 文件中的“Rows Affected Parameter”,那么并发错误也将按预期工作。
我发现,这种解决方案(即使用输出参数)在这里得到了最好的解释:http://petermannerhult.wordpress.com/2010/10/01/entity-framework-4-with-optimistic-concurrency-and-stored-procedures/
然而,以上两个步骤似乎都不应该是必要的,因为我认为Entity Framework可以只使用更新的行数来确定是否应引发并发异常。我在 ADO.NET 数据集中使用这些完全相同的存储过程(使用乐观并发),没有任何问题。所以我的问题是,如何在不修改现有存储过程的情况下,使用这些存储过程启用 Entity Framework 中的乐观并发?
RecordsAffected
属性。我可以猜测各种可能的原因,但最终只有 EF 产品开发人员才能确定。而且为什么会这样并不重要,重要的是它就是不能这样工作。 - RBarryYoung