Page 1 of 1
change in behaviour dotconnect 6.30
Posted: Tue 09 Aug 2011 10:15
by wgkwvl
Hi,
I installed the latest version of dotconnect for oracle ( 6.3.xxx),
and notice the following new and strange behaviour :
the following statement gets issued :
UPDATE AFDA.AFDA_PATIENTEN
SET PATIENT_NR = PATIENT_NR WHERE PATIENT_NR = :p0 AND WIJZIGING_DT = :p1
The field Patient_Nr is primary key, the field Wijziging_Dt is concurrency field.
My window will show a patient and some related records ,
when adding a new related record to the patient, it is the patient that is sent to Entity Framework to be saved, so that all related objects are also saved -> hence the saving of a patient that has not been changed.
The previous version of dotconnect that i used ( 6.0.xxx) did not generate this statement.
this is a breaking change for me , since some triggers will get fired this way, that i dont expect to be fired , Is there a way to prevent this ?
As in
http://www.devart.com/forums/viewtopic. ... highlight= , there is no inheritance for the patient and relates records
Posted: Tue 09 Aug 2011 15:36
by Shalex
Please use dbMonitor to perform per-component tracing of SQL statement execute.
Download link:
http://www.devart.com/dbmonitor/dbmon3.exe
Documentation:
http://www.devart.com/dotconnect/oracle ... nitor.html
In dbMonitor you can find that dotConnect for Oracle v 6.00 sends some SELECT statements (instead of UPDATE) to the database. This is not correct. So we have implemented functionality of EF-provider in the 6.30 version more completely. A decision that object is modified and has to be updated is made by ObjectStateManager (
http://msdn.microsoft.com/en-us/library ... nager.aspx) and run-time EF engine.
We are going to implement the possibility to turn off optionally fake updates for the case when such functionality is not taken into account by the logic of user's triggers. We will post here about the results.
Posted: Tue 09 Aug 2011 15:56
by Shalex
We have implemented the possibility to turn off generation of fake updates for parent entities:
Code: Select all
var config = Devart.Data.Oracle.Entity.Configuration.OracleEntityProviderConfig.Instance;
config.DmlOptions.EmptyUpdates = false;
This functionality will be included to the next build of dotConnect for Oracle. We will post here when it is available for download.
Posted: Wed 10 Aug 2011 13:34
by wgkwvl
I look forward to this version.
When i Inspect the
context.ObjectStatemanger._unchangedEntityStore , i will find my patient with entity state 'unchanged' ,
so it must be an EF runtime thing
Posted: Thu 11 Aug 2011 08:21
by wgkwvl
Something in the way transactions are handled must also have changed, because i suddenly have locks in my database that are not release on commit of my transaction scope ..
any hints ?
Posted: Thu 11 Aug 2011 15:24
by Shalex
Could you please
send us a small test project with your model and corresponding DDL/DML script to reproduce the issue with handling transactions in our environment?
Each SaveChanges() is executed in its own local transaction, so usually there is no need to use distributed transaction.
Posted: Fri 12 Aug 2011 10:55
by wgkwvl
Hi,
I havent been able to reproduce the issue in a controlled environment yet,
I just made the mistake of rolling it out to production , and learn about this problem the hard way.
Atm we are using this logic for transactions :
public TransactionScope StartTransaction()
{
AfdaEntities context = _context as AfdaEntities;
if (context == null)
throw new InvalidCastException("Cannot cast Context to AfdaEntities");
TransactionOptions transactionOptions = GetTransactionOptions();
TransactionScope trans = new TransactionScope(TransactionScopeOption.Required, transactionOptions);
if (context.Connection.State != ConnectionState.Open)
context.Connection.Open();
return trans;
}
public TransactionOptions GetTransactionOptions()
{
TransactionOptions transactionOptions = new TransactionOptions(); transactionOptions.IsolationLevel = System.Transactions.IsolationLevel.ReadCommitted; return transactionOptions;
}
public void CommitTransaction(TransactionScope trans)
{
if (trans != null)
{
trans.Complete();
trans.Dispose();
}
}
public void RollBackTransaction(TransactionScope trans)
{
if (trans != null)
trans.Dispose();
}
We don't explicitly bind the transaction to the context and viceversa,
and don't use any devart - properties/classes for transactions
This code however works fine in 6.0.00. ( and does not at first glance give problems in 6.3.xx, but might be responsible for my locking problems )
Posted: Fri 12 Aug 2011 15:09
by Shalex
New build of dotConnect for Oracle 6.30.202 is available for download!
It can be downloaded from
http://www.devart.com/dotconnect/oracle/download.html (trial version) or from Registered Users' Area (for users with valid subscription only):
http://secure.devart.com/ . For more information, please refer to
http://www.devart.com/forums/viewtopic.php?t=21724 .
This build includes the possibility to turn off generation of fake updates for parent entities.