Unnecessary Timestamp Update on Non-changed Entities

Discussion of open issues, suggestions and bugs regarding Entity Framework support in ADO.NET Data providers
Post Reply
Posts: 8
Joined: Wed 22 Sep 2010 14:16

Unnecessary Timestamp Update on Non-changed Entities

Post by Oktane » Wed 25 May 2011 17:13

Hi we are seeing an issue when using Optimistic Concurreny with EF / Devart Oracle Connect.

Our DB structure is this

ContractVersion Table (Master Table)
- Counterparty Table (related to ContractVersion)
- Delivery Table (related to ContractVersion)

Which Translates into the following DTO's (we are using POCO STE's)
ContractVersion containing
- List of 1..N Counterparties
- List of 1..N Deliveries

All 3 tables have a timestamp column. The Timestamp for each is updated with a trigger on the Oracle DB. We currently have (and I have checked the xml in the .edml/.edmx) the Timestamp columns set to StoreGeneratedPattern=Computed and the ConcurrencyMode=Fixed.

When we change all the entities Or the parent Entity (ie the ContractVersion), the Optimistic Concurrency works perfectly. However we have a specific case that we cannot figure out.

If we make a change to the Delivery Entity or the Counterparty Entity, the resulting Update commands for these tables are generated correctly. However, in addition we also have an additional Update of the ContractVersion table, that updates nothing but the Timestamp column (See below for the query picked up via EF Profiler). We have validated that the ContractVersion Entity has no changes (ie its not in a modified/changed state), so are confused as to why this update is being called.

Anybody got any ideas?

The additional command, which is called before the actual changes are executed is as follows -
updatedRowid ROWID;

TIMESTAMP = '25/05/2011 17:33:21 +01:00' /* @p1 */
OPEN '' /* @outParameter */ FOR SELECT
WHERE ROWID = updatedRowid;

Site Admin
Posts: 8239
Joined: Thu 14 Aug 2008 12:44

Post by Shalex » Tue 31 May 2011 08:27

Sorry for the delay.

Entity Framework engine makes EF-provider (dotConnect for Oracle in this case) generate UPDATE commands for all ancestors of modified entity. If entities-ancestors were not changed, UPDATE (empty) should be created any way. So this behaviour is as designed by Microsoft, and our provider implements this logic.

As we consider on our own and basing on feedbacks from other users, such behaviour is acceptable if the table, the base class of hierarchy is mapped to, has UPDATE-trigger which makes additional actions before/after any update in hierarchy.

It is possible to implement an optional behaviour in one of the next releases of dotConnect for Oracle when empty updates will not be sent to database. Please add this suggestion to our EF UserVoice: http://devart.uservoice.com/forums/1051 ... rk-support.

Post Reply