This content has been marked as final. Show 4 replies
What is your question exactly? A way to have ODP.NET avoid checking for dirty writes?
What is exactly weird about the behavior?
This error is that user object is marked dirty erroneously by ODP I am guessing. We just create a new object and use it as a foreign key reference, as in the following pseudo code
User user = new User()
user.EntityKey = ...
myObject.User = user;
This somehow makes the user record dirty and issues update statement I posted. Primary key is certainly not changed, so why is it being updated?
Edited by: Sergey Barskiy on May 1, 2013 2:02 PM
Do you mind emailing a reproducible test case to dotnet_us(at)oracle.com as a zip file? The simpler the test case, the better. It's not obvious, even with the pseudocode, whether the dirty write check or the locking is caused by an EF command tree issue or an ODP.NET issue. Having a test case will allow us to pinpoint how a fix (or workaround) can be made.
Thanks for following up, Alex. We are unable to reproduce this issue. One of our customers is having the problem, but we are unable to narrow down the exact area, because all the provide is the statement they capture in Oracle. The piece of software is very large, and it is close to impossible to find out exact spot. Hence, I was wondering if someone else maybe reported the same thing (or similar) and there was some patch we could use...
Sorry I do not have better info, we just do not have access to it.