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.
Search found 25 matches
- Mon 08 Oct 2012 11:59
- Forum: dotConnect for Oracle
- Topic: Full Temp Space Bug with CLOB Fields in Direct Mode
- Replies: 13
- Views: 15336
- 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?
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?
- Tue 07 Jun 2011 15:09
- Forum: dotConnect for Oracle
- Topic: Full Temp Space Bug with CLOB Fields in Direct Mode
- Replies: 13
- Views: 15336
- Tue 07 Jun 2011 11:55
- Forum: dotConnect for Oracle
- Topic: Full Temp Space Bug with CLOB Fields in Direct Mode
- Replies: 13
- Views: 15336
- Mon 02 May 2011 15:58
- Forum: dotConnect for Oracle
- Topic: Full Temp Space Bug with CLOB Fields in Direct Mode
- Replies: 13
- Views: 15336
- Wed 20 Apr 2011 07:35
- Forum: dotConnect for Oracle
- Topic: Full Temp Space Bug with CLOB Fields in Direct Mode
- Replies: 13
- Views: 15336
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:
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:
We tested with Devart dotConnect for Oracle v6.10.135.0.
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:
With some analysis, we found that the temporary space was being filled and never released, until we shutdown our application.ORA-01652: unable to extend temp segment by 128 in tablespace TEMP
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:
Could it be that this bug was fixed for the Oracle Client but not for Direct Mode? When will this bug be fixed?Fixed bug with freeing temporary tablespace when creating multiple LOBs
We tested with Devart dotConnect for Oracle v6.10.135.0.
- Mon 18 Apr 2011 13:02
- Forum: dotConnect for Oracle
- Topic: NullReferenceException with Distributed Transaction.
- Replies: 10
- Views: 2509
- 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.
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.
- Tue 29 Mar 2011 08:55
- Forum: dotConnect for Oracle
- Topic: NullReferenceException with Distributed Transaction.
- Replies: 10
- Views: 2509
- 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:
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:
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:
Which was successful, and resulted in the following Oracle query:
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.
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
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)
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
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 am using dotConnect for Oracle Professional 6.10.126.0.
- Wed 09 Mar 2011 12:33
- Forum: dotConnect for Oracle
- Topic: NullReferenceException with Distributed Transaction.
- Replies: 10
- Views: 2509
- 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:
I get the System.Data.EntityCommandExecutionException exception with the following error message: ORA-00932: inconsistent datatypes: expected - got CLOB
However, the following query works:
And this query also works:
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:
The second query:
The third query:
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.
- Name: VARCHAR2(50)
Value: CLOB
Code: Select all
var results = context.CreateQuery("SELECT VALUE m FROM Metadatas WHERE m.Value = 'Value1'").ToList();
However, the following query works:
Code: Select all
var results = context.Metadatas.Where(x => x.Value == "Value1").ToList();
Code: Select all
results = context.CreateQuery("SELECT VALUE m FROM Metadatas AS m WHERE m.Value = @v", new ObjectParameter("v", "Value1")).ToList();
Code: Select all
SELECT
"Extent1".ID AS ID,
"Extent1".NAME AS NAME,
"Extent1".VALUE AS VALUE
FROM METADATA "Extent1"
WHERE "Extent1".VALUE = 'Value1'
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')
Code: Select all
SELECT
"Extent1".ID AS ID,
"Extent1".NAME AS NAME,
"Extent1".VALUE AS VALUE
FROM METADATA "Extent1"
WHERE "Extent1".VALUE LIKE :v
I am using Devart dotConnect for Oracle Professional 6.0.86.0.
- Mon 17 Jan 2011 08:46
- Forum: dotConnect for Oracle
- Topic: NullReferenceException with Distributed Transaction.
- Replies: 10
- Views: 2509
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();
}
- Fri 14 Jan 2011 11:54
- Forum: dotConnect for Oracle
- Topic: NullReferenceException with Distributed Transaction.
- Replies: 10
- Views: 2509
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:
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.
Does anyone have any idea what the issue is?
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)
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());
}
}
- 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.
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.