Devart Forums

ruda wrote: ↑Mon 09 May 2022 12:43 But if it is an integer field (bigint, int...) the problem occurs.

loganfox wrote: ↑Thu 24 Mar 2022 10:06 Update since my original post In case it helps, I've also just tried using the OracleCommand approach to negate anything to do with EF/Devart. I'm still seeing the same performance hit when it comes to those clobs. In the below rough example, 13 records take around 14 seconds to be iterated. If I comment out the two clob fields, iteration is fast/near instant. In other test runs using 'Direct=true' in the connection string didn't help much/do anything noticeable to improve performance.

Code: Select all

var con = new OracleConnection("connstringhere");
con.Open();
var cmd = new OracleCommand();
cmd.Connection = con;
cmd.CommandText = "SELECT * FROM tableA WHERE condition1='Y' and condition2 = 'Y'";
OracleDataReader dr = cmd.ExecuteReader();

while (dr.Read())) {
  var d1 = dr["ID"];
  var d2 = dr["CLOBFIELD1"];
  VAR d3 = dr["CLOBFIELD2"];
}

PeterUser wrote: ↑Tue 26 Apr 2022 08:27 I have performance issues with NCLOB columns in tables and I read that setting InitialLobFetchSize of the OracleCommand can fix that issue.

Is there a way to set this option for an EF DbContext?

Maybe something like

Code: Select all

// Not working!
OracleEntityProviderConfig.Instance.QueryOptions.InitialLobFetchSize = -1;

PeterUser wrote: ↑Wed 27 Apr 2022 12:52 I did additional investigation and tried implementing an IDbCommandInterceptor. Unfortunately, the returned DbCommand is not an OracleDbCommand, but a Devart.Data.Oracle.Entity.ag, which does not have an InitialLobFetchSize property.