OracleException - Network error: 200 writing large BLOB

[b1010101]

Hello.
I've encountered the above problem when I try to update a large blob.
If blob is small then everything is OK.
I've set ConnectionTimeout in both connection string and OracleCommand to 1800, but it hasn't helped.
Blob update is the same as in examples (new Blob is created, then assigned to OracleCommand as parameter).
Exception details are below.
What could be the problem here?

[Edit] When pooling is off (Pooling=false in the connection string), then exception is thrown after ~30 seconds after call of cmd.ExecuteNonQuery().
When pooling was set to default value then exception was thrown after ~3 mins.
[Edit2] Version 5.25.49.0 is used.

Devart.Data.Oracle.OracleException occurred
Message="Network error: 200"
Source="Devart.Data.Oracle"
ErrorCode=-2147467259
Code=200
Offset=0
StackTrace:
at Devart.Data.Oracle.o.a(Int32 A_0)
at Devart.Data.Oracle.ab.i()
at Devart.Data.Oracle.ab.d()
at Devart.Data.Oracle.aw.o()
at Devart.Data.Oracle.a7.c(Int32 A_0, Byte[] A_1, Int32 A_2, Int32 A_3)
at Devart.Data.Oracle.a7.a(Int32 A_0, Byte[] A_1, Int32 A_2, Int32 A_3)
at Devart.Data.Oracle.OracleLob.WriteLobCache(Boolean clearLob)
at Devart.Data.Oracle.OracleLob.b()
at Devart.Data.Oracle.OracleLob.f()
at Devart.Data.Oracle.OracleParameter.a(OracleDbType A_0, Object A_1, Byte[] A_2, Hashtable A_3, Int32 A_4, Int32 A_5, Int32 A_6, Int32 A_7, Int32 A_8, Boolean A_9, OracleConnection A_10, ParameterDirection A_11, String A_12, aw A_13, Boolean& A_14)
at Devart.Data.Oracle.OracleParameter.a(ar& A_0, Boolean A_1, OracleConnection A_2, Byte[] A_3, Hashtable A_4, aw A_5, Boolean& A_6)
at Devart.Data.Oracle.OracleCommand.a(aa A_0, Int32 A_1, OracleParameterCollection A_2, aw A_3, Boolean& A_4)
at Devart.Data.Oracle.OracleCommand.InternalExecute(CommandBehavior behavior, IDisposable disposable, Int32 startRecord, Int32 maxRecords)
at Devart.Common.DbCommandBase.ExecuteDbDataReader(CommandBehavior behavior)
at System.Data.Common.DbCommand.ExecuteReader()
at Devart.Data.Oracle.OracleCommand.ExecuteNonQuery()
at ....

[Shalex]

Try increasing (or setting to 0 - unlimited) the CommandTimeout property of OracleCommand, not ConnectionTimeout of OracleConnection. We recommend you using the latest 5.35.57 version of dotConnect for Oracle. Does the problem persist with the latest version? If yes, please give us the following information to reproduce the issue in our environment:
1) your current versions of dotConnect for Oracle, Oracle server, and Oracle client (if you are connecting via OCI);
2) the connection string you are using;
3) post here or send us the code you are using to update the blob fields and the DDL script;
4) tell us the exact size of your "large blob" you are experiencing difficulties with.

[b1010101]

I've updated to latest 5.35.57 version.
It hasn't helped.

When I create Oracle Command, its timeout is automatically set to 0 as I can see in the debugger.

1. Dotconnect 5.35.57, oracle 10.2.0.1.0.
2. Connection string User Id=***;Password=***;Server=***;Persist Security Info=True;direct=True;Unicode=true;Connection Timeout=1800;sid=empty3
3.

Code: Select all

CREATE TABLE DOCUMENTS.TFILES
(
  FDOCUMENTID  NUMBER(10)                       NOT NULL,
  FVERSION     NUMBER(10)                       NOT NULL,
  FDATA        BLOB                             NOT NULL
)
LOGGING 
NOCOMPRESS 
NOCACHE
NOPARALLEL
MONITORING
/

Code: Select all

        private void TransferChunksToDb(Guid id, long docID, long version)
        {
            DbConnection connection = ((EntityConnection)ctx.Connection).StoreConnection;
            OracleConnection conn = (OracleConnection)connection;

            DirectoryInfo info = new DirectoryInfo(ConfigurationManager.AppSettings["UploadTempPath"] + id.ToString());
            int chunks = info.GetFiles().Count();
            OracleLob blob = new OracleLob(conn, OracleDbType.Blob);
            {

                for (int i = 1; i  0)
                        {
                            // Read may return anything from 0 to numBytesToRead.
                            int n = fs.Read(daatta, numBytesRead, numBytesToRead);

                            // Break when the end of the file is reached.
                            if (n == 0)
                            {
                                break;
                            }

                            numBytesRead += n;
                            numBytesToRead -= n;
                        }
                        blob.Write(daatta, 0, (int)fs.Length);
                    }
                }
            }

4. I was only able to write ~2.2 mb file (my Oracle server is on another computer and network bandwith ~250 kbytes/seconds).

Strangely, with file > ~3 mbytes (now I am testing with 3.3) I 've started getting another error in cmd.ExecuteNonQuery (it wasn't so when I used old version of dotCOnnect from my first post). But connection is obviously opened (I can see that in the debugger and can upload 2.2. mb blob).

System.InvalidOperationException occurred
Message="Connection must be opened."
Source="Devart.Data.Oracle"
StackTrace:
at Devart.Data.Oracle.OracleConnection.g()
at Devart.Data.Oracle.OracleCommand.InternalExecute(CommandBehavior behavior, IDisposable disposable, Int32 startRecord, Int32 maxRecords)
at Devart.Common.DbCommandBase.ExecuteDbDataReader(CommandBehavior behavior)
at System.Data.Common.DbCommand.ExecuteReader()
at Devart.Data.Oracle.OracleCommand.ExecuteNonQuery()

Please note that blob.Write is called multiple times in both of these cases (2.2. and 3.3 mb).

I have a deadline on this functionality, could you help me out with this?

[Shalex]

We have sent you a test project to your e-mail. We cannot reproduce the issue at the moment.

[b1010101]

It seems that it was a error in my code. There was a timer callback that was closing the connection when ExecuteNonQuery was called. That's why I was getting System.InvalidOperationException occurred
Message="Connection must be opened.".

Network error 200 has gone away.

Anyways I've rewritten my code using another approach.

Thanks you guys for support.