PROBLEMS WITH ODAC 6.10.0.9

Discussion of open issues, suggestions and bugs regarding ODAC (Oracle Data Access Components) for Delphi, C++Builder, Lazarus (and FPC)
Post Reply
usuarioincorrecto
Posts: 18
Joined: Thu 28 Jun 2007 12:43

PROBLEMS WITH ODAC 6.10.0.9

Post by usuarioincorrecto » Thu 28 Jun 2007 13:13

Hi;

First of all, please forgive my poor English grammar, but I'm Spanish and I know my English is not good enough. I'll do my best.

I work with Delphi and Oracle 10G in Direct Mode, this is WITH NO ORACLE CLIENT.
The problem usually occurs when I display a large amount of records (more than 10,000 records) in a Grid... sometimes with 2000 records it also fails.

What I have seen is that, when the FETCHROWS Property of a TOraQuery is set to 25 (FETCHALL = FALSE) , and I press the Key "End" in my keyboard, to go to the last record in the Grid, Delphi Raises an "ACCESS VIOLATION".

When I accept the error, the Grid does not show any record, it remains in blank, due to that error... but If I press the Key "End" again, ¡¡ The grid recovers many records !!! ... BUT CURIOUSLY 25, 50....125....200.... this is, always related with the FETCHROWS property. (FETCHROWS * 2, FETCHROWS * 15... ).. Always multiplied.
I must say, that the TOraQuery has very complex opperations in the ONCALCFIELDS, but It works CORRECTLY with a PREVIOUS ODAC version (4.50.1.18).
If I make this opperation, If I show the SAME data with a previous ODAC version (4.50.1.18), it works OK, curiously despite this ODAC version was not recommended for Oracle 10g... It works OK. It does not raise any exception. WHY ????


If I show a QUERY with NO CALCULATED FIELDS, with the ODAC 6.10.0.9 works ok, in Direct Mode.... The PROBLEM SEEMS TO BE when using CALCULATED FIELDS, MEMORY.... FETCHROWS WITH ORACLE 10g AND ODAC 6.10.0.9... I don't know what to think.

I have more to tell...
Another problem, related to the FETCHROWS property (don't know why it worked in ODAC 4.50.1.18 and not with this one), is when you show a QReport with "many" data... It usually raises an exception: "Invalid Metafile"... "Cannot create file €♫m file" (odd characters)... and "Access Violation".

I have read about this in the Web, and many people told me it was caused because of the "possible" Lack of Memory, etc...
Well... I'm running the application in a 10 GB RAM PC, and the Database Server has the same hardware configuration.
If I run the application in my client against the server (I told you before I have NO ORACLE CLIENT, I work in Direct Mode), some Qreports works ok... but If I run the application in the Server, the same reports fail...

I want to know WHY does my application work with ODAC 4.50.1.18 with ORACLE CLIENT, using a TOraQuery with CALCULATED FIELDS, ... It does not raise ANY EXCEPTION... but now with this version it fails a lot.

Please... Have you any idea?. Could you help me with this?

Thank You Very Much.

tuasal
Posts: 20
Joined: Wed 11 Apr 2007 08:56

Post by tuasal » Fri 29 Jun 2007 03:53

I wish to confirm presence of a problem from at least version 6.05.0.7.
In DataSet with large amount of records (2000 happens enough) exception occured after call of method Last() - for example after pressing button 'Last' in DBNavgator.

Thus call stack looks as follows:
------------------------------------------------
CLRClasses.pas > Marshal.ReadIntPtr()
...
OraClasses.pas > TOCIRecordSet.FetchArray()
OraClasses.pas > TOCIRecordSet.Fetch()
OraClasses.pas > TOCIRecordSet.DoFetchAll()
OraClasses.pas > TOCIRecordSet.FetchAll()
OraClasses.pas > TOCIRecordSet.SetToEnd()
MemDS.pas > TMemDataSet.InternalLast()
DB.pas > TDataSet.Last()
...
------------------------------------------------

Error repeats steadily. Error not connected with structure of the concrete table.
I'm using Oracle 9.2.0.7.
OraSession.Options.Direct=false.

usuarioincorrecto
Posts: 18
Joined: Thu 28 Jun 2007 12:43

WHAT CAN I DO???

Post by usuarioincorrecto » Fri 29 Jun 2007 08:55

Hi Again, and thank you, tuasal.

Are you trying to tell me that the Last() dethod fails with this ODAC Version, the 6.10.0.9 NET ???. (I'm spanish, and I know my English is not good enough... please forgive me).

This is a very used procedure to fail in an application !!!

What can I do?. How can I solve this? ...

It is supposed we have to install our application in few days, and with this bug, we are quite surprised and don't know what to do.

Is there any solution?

Thank you, friend.

Challenger
Devart Team
Posts: 925
Joined: Thu 17 Nov 2005 10:53

Post by Challenger » Mon 02 Jul 2007 07:07

We couldn't reproduce this error using information you have specified. Please send to ODAC support address complete sample that demonstrates this problem and include script to create server objects.

tuasal
Posts: 20
Joined: Wed 11 Apr 2007 08:56

Post by tuasal » Mon 23 Jul 2007 04:42

Yes, the method Last() fails, but under some conditions, all of listed below:
1) at least one lookup field (FieldKind = fkLookup) created in dataset object.
2) amount of records is large enough. At me the problem repeats steadily at quantity of records is 100000 or higher.
3) database table contains text columns (VARCHAR2) with large enough length - shall tell, 64 chars. For schema SCOTT the problem (like) is not shown
if text fields have default length, but problem occurs after increasing the lengths, for example, to 64. And it is not necessarily that this text field (corresponding TField object) has been created in dataset object (TOraTable, etc.).

ps. I have sent the example to the ODAC support.

tuasal
Posts: 20
Joined: Wed 11 Apr 2007 08:56

Post by tuasal » Mon 23 Jul 2007 10:20

Sometimes the described error (exception with the same call stack, as in case of a mistake described above) raised at absolutely small amount of records - less than 10 (but lookup fields and text fields with concerning "big" length are still present).

Challenger
Devart Team
Posts: 925
Joined: Thu 17 Nov 2005 10:53

Post by Challenger » Tue 24 Jul 2007 07:56

We have reproduced and fixed the problem using the sample from tuasal. This fix will be included in the next build of ODAC.

Post Reply