Search found 25 matches

by mas
Mon 08 Oct 2012 11:59
Forum: dotConnect for Oracle
Topic: Full Temp Space Bug with CLOB Fields in Direct Mode
Replies: 13
Views: 15334

Re: Full Temp Space Bug with CLOB Fields in Direct Mode

Hi, it has been a long time since I have reported this issue, and this issue still persists with the newest version (7.2.96).

Our current workaround is to set "Connection Lifetime=60" in the connection string. This ensures that all connections will be closed often, which forces the temp spaced to be cleaned up.

Is there a plan to fix this? If the plan is not to fix this bug, then it would be nice to know so we can search for other solutions.
by mas
Thu 30 Jun 2011 15:30
Forum: dotConnect for Oracle
Topic: License compatibility with previous version
Replies: 3
Views: 1447

A library is compiled with a license from an older version of the connecter.

I'm building an application with a license for a never version of the connector. Even though I have both DLLs available to the application, I get an exception that the library cannot find the old DLL.

What is the best practices for handling different versions of the Devart connector? It seems to me that every new version would require us to rebuild every single library and application, which is a maintenance nightmare.

Is is usually better to have the license built into the library, or into the application?
by mas
Tue 07 Jun 2011 15:09
Forum: dotConnect for Oracle
Topic: Full Temp Space Bug with CLOB Fields in Direct Mode
Replies: 13
Views: 15334

I have tested with dotConnect for Oracle 6.30.165, and the problem still occurs. A fix for this is quite urgent for us...
by mas
Tue 07 Jun 2011 11:55
Forum: dotConnect for Oracle
Topic: Full Temp Space Bug with CLOB Fields in Direct Mode
Replies: 13
Views: 15334

According to the release notes for dotConnect for Oracle 6.30.165:
The bug with retrieving LOB values in Direct mode is fixed
Is this issue fixed?
by mas
Mon 02 May 2011 15:58
Forum: dotConnect for Oracle
Topic: Full Temp Space Bug with CLOB Fields in Direct Mode
Replies: 13
Views: 15334

Hi, is there a workaround that we can employ while we're waiting for the fix? We are currently running performance tests and we often run into this issue.
by mas
Wed 20 Apr 2011 07:35
Forum: dotConnect for Oracle
Topic: Full Temp Space Bug with CLOB Fields in Direct Mode
Replies: 13
Views: 15334

Full Temp Space Bug with CLOB Fields in Direct Mode

I have already reported several issues with CLOB fields in Direct Mode, and I have run into another.

We have some tables with CLOB columns. During our performance testing, we inserted a large number of rows into these tables. Eventually, our application started erroring out with the message from Oracle:
ORA-01652: unable to extend temp segment by 128 in tablespace TEMP
With some analysis, we found that the temporary space was being filled and never released, until we shutdown our application.

This problem occurs only in Direct Mode. We tested with the Oracle Client and we didn't run into this problem.

In the change history (http://www.devart.com/History.aspx?prod ... ect/oracle), I found this entry for 6.00.69 16-Dec-10:
Fixed bug with freeing temporary tablespace when creating multiple LOBs
Could it be that this bug was fixed for the Oracle Client but not for Direct Mode? When will this bug be fixed?

We tested with Devart dotConnect for Oracle v6.10.135.0.
by mas
Mon 18 Apr 2011 13:02
Forum: dotConnect for Oracle
Topic: NullReferenceException with Distributed Transaction.
Replies: 10
Views: 2507

I have confirmed that this problem is now fixed by testing my sample application against the new version. Thanks!
by mas
Tue 29 Mar 2011 09:00
Forum: dotConnect for Oracle
Topic: TIMESTAMP WITH TIMEZONE daylight savings bug
Replies: 4
Views: 2315

TIMESTAMP WITH TIMEZONE daylight savings bug

I have an application that records 2 timestamps in a table, both columns are of type TIMESTAMP WITH TIMEZONE.

The first column, APP_RECEIVE_TIME, is set by our .NET application.
The second column, DB_INSERT_TIME, is set by our database via the column's default value.

After the daylight savings time switch-over, I found that the APP_RECEIVE_TIME was incorrect. It contained the local time with the wrong offset value. The expected offset value was +02:00.

Example:
APP_RECEIVE_TIME: 28-MAR-11 05.03.53.226108 PM +01:00
DB_INSERT_TIME: 28-MAR-11 05.03.54.277826 PM +02:00

I would like to note that I am using Direct=true, because I have previously run into a bug with TIMESTAMP WITH TIMEZONE and Direct=true (http://www.devart.com/forums/viewtopic.php?t=19911).

This problem has been observed in dotConnect for Oracle 6.10.96.0.

Edit

We tested with Direct=false (with Oracle Client), and the offset is set correctly. The problem only occurs with Direct=true.
by mas
Tue 29 Mar 2011 08:55
Forum: dotConnect for Oracle
Topic: NullReferenceException with Distributed Transaction.
Replies: 10
Views: 2507

I have tested this again with version 6.10.126.0, and I still see the problem. I have updated the test project to illustrate the issue more clearly, and have e-mailed it in.
by mas
Thu 24 Mar 2011 13:06
Forum: dotConnect for Oracle
Topic: Problem with CAST of CLOB types.
Replies: 3
Views: 1446

Problem with CAST of CLOB types.

I have a table, Metadata, with the columns:

Name: VARCHAR2(50)
Value: CLOB

I try to execute the following Entity SQL query, where @p is an integer:

Code: Select all

SELECT VALUE m FROM Metadata AS m WHERE m.Name = 'NumberValue' AND CAST(m.Value as System.Int32) > @p
However, I get the exception with the message: ORA-00932: inconsistent datatypes: expected NUMBER got CLOB

I looked into dbMonitor, and I found that the resulting Oracle query was:

Code: Select all

SELECT 
"Extent1".WF_INSTANCE_ID AS WF_INSTANCE_ID, 
"Extent1".NAME AS NAME, 
"Extent1".VALUE AS VALUE, 
"Extent1".SERIALIZED_VALUE AS SERIALIZED_VALUE
FROM METADATA "Extent1"
WHERE ("Extent1".NAME = 'NumberValue') AND ((CAST("Extent1".VALUE AS NUMBER)) > :p)
The problem is that a CLOB cannot be casted to NUMBER. It must be first casted to VARCHAR then to NUMBER. Following this logic, I tried the following Entity SQL query:

Code: Select all

SELECT VALUE m FROM Metadata AS m WHERE m.Name = 'NumberValue' AND CAST(CAST(m.Value as System.String) as System.Int32) > @p
Which was successful, and resulted in the following Oracle query:

Code: Select all

SELECT 
"Extent1".WF_INSTANCE_ID AS WF_INSTANCE_ID, 
"Extent1".NAME AS NAME, 
"Extent1".VALUE AS VALUE, 
"Extent1".SERIALIZED_VALUE AS SERIALIZED_VALUE
FROM METADATA "Extent1"
WHERE ("Extent1".NAME = 'NumberValue') AND ((CAST( TO_CHAR("Extent1".VALUE) AS NUMBER)) > :p)
I get a similar error message when I try to CAST a CLOB to System.DateTime and System.DateTimeOffset.

I am using dotConnect for Oracle Professional 6.10.126.0.
by mas
Wed 09 Mar 2011 12:33
Forum: dotConnect for Oracle
Topic: NullReferenceException with Distributed Transaction.
Replies: 10
Views: 2507

I have sent in a test project to illustrate the issue.
by mas
Wed 26 Jan 2011 14:25
Forum: dotConnect for Oracle
Topic: Bug Querying CLOB Columns using Entity SQL.
Replies: 2
Views: 1168

Bug Querying CLOB Columns using Entity SQL.

I have a table, Metadata, with the columns:
  • Name: VARCHAR2(50)
    Value: CLOB
When I execute the following query using Entity SQL,

Code: Select all

var results = context.CreateQuery("SELECT VALUE m FROM Metadatas WHERE m.Value = 'Value1'").ToList();
I get the System.Data.EntityCommandExecutionException exception with the following error message: ORA-00932: inconsistent datatypes: expected - got CLOB

However, the following query works:

Code: Select all

var results = context.Metadatas.Where(x => x.Value == "Value1").ToList();
And this query also works:

Code: Select all

results = context.CreateQuery("SELECT VALUE m FROM Metadatas AS m WHERE m.Value = @v", new ObjectParameter("v", "Value1")).ToList();
I looked into DB Monitor to see what was going on, and I found that the first query (the error case) produced the following SQL:

Code: Select all

SELECT 
"Extent1".ID AS ID, 
"Extent1".NAME AS NAME, 
"Extent1".VALUE AS VALUE
FROM METADATA "Extent1"
WHERE "Extent1".VALUE = 'Value1'
The second query:

Code: Select all

SELECT 
"Extent1".ID AS ID, 
"Extent1".NAME AS NAME, 
"Extent1".VALUE AS VALUE
FROM METADATA "Extent1"
WHERE "Extent1".VALUE LIKE TO_CLOB('Value1')
The third query:

Code: Select all

SELECT 
"Extent1".ID AS ID, 
"Extent1".NAME AS NAME, 
"Extent1".VALUE AS VALUE
FROM METADATA "Extent1"
WHERE "Extent1".VALUE LIKE :v
It seems in the first case, there a bug where no special handling done for comparing CLOB values.

I am using Devart dotConnect for Oracle Professional 6.0.86.0.
by mas
Mon 17 Jan 2011 08:46
Forum: dotConnect for Oracle
Topic: NullReferenceException with Distributed Transaction.
Replies: 10
Views: 2507

We found a workaround to this issue, if we create a new TransactionScope with the RequiresNew option, then this error does not occur.

Code: Select all

using (var ts = new TransactionScope(TransactionScopeOption.RequiresNew))
{
	using (var context = new DatabaseEntities())
	{
		// Do database changes...
	}

	ts.Complete();
}
by mas
Fri 14 Jan 2011 11:54
Forum: dotConnect for Oracle
Topic: NullReferenceException with Distributed Transaction.
Replies: 10
Views: 2507

NullReferenceException with Distributed Transaction.

I am using Devart dotConnect for Oracle Professional 6.0.58.0.

I have an application where Worflows are instantiated from messages from MSMQ. When reading a message from MSMQ, it automatically creates a transaction, probably using TransactionScope.

Within this transaction, we have some custom code that writes to the database. However, we receive the following exception:

Code: Select all

Exception: System.NullReferenceException
Message: Object reference not set to an instance of an object.
StackTrace: at Devart.Common.r.d()
at Devart.Common.r.a(Enlistment A_0)
at System.Transactions.Oletx.OletxVolatileEnlistment.Rollback()
at System.Transactions.Oletx.OletxPhase1VolatileEnlistmentContainer.Aborted()
at System.Transactions.Oletx.OletxTransactionManager.ShimNotificationCallback(Object state, Boolean timeout)
at System.Threading._ThreadPoolWaitOrTimerCallback.PerformWaitOrTimerCallback(Object state, Boolean timedOut)
I have tried to reproduce this in a sample application, however, I was unable to reproduce this problem.

A quick look through Reflector reveals the code below. My feeling is that the Transaction is null, causing the exception.

Code: Select all

public void d()
{
    lock (b.SyncRoot)
    {
        b.Remove(this.c.Transaction.GetHashCode());
    }
}
Does anyone have any idea what the issue is?
by mas
Mon 10 Jan 2011 09:09
Forum: dotConnect for Oracle
Topic: do you recommend Direct=true?
Replies: 2
Views: 1070

If you are using TIMESTAMP WITH TIMEZONE columns, you might experience inconsistent behaviour with respect to the timezone offset, depending on if you use Direct mode or not.

I posted the issue here: http://www.devart.com/forums/viewtopic.php?t=19911

We use Entity Framework, and so far, we have not run into any limitations of Direct mode, it works great besides the said issue.