change in behaviour dotconnect 6.30
change in behaviour dotconnect 6.30
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
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
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.
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.
We have implemented the possibility to turn off generation of fake updates for parent entities:
This functionality will be included to the next build of dotConnect for Oracle. We will post here when it is available for download.
Code: Select all
var config = Devart.Data.Oracle.Entity.Configuration.OracleEntityProviderConfig.Instance;
config.DmlOptions.EmptyUpdates = false;
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.
Each SaveChanges() is executed in its own local transaction, so usually there is no need to use distributed transaction.
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 )
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 )
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.
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.