Access Violation at TOracleDataSet.Open() method

Rulikkk

Member
Sometimes, when the program is working for quite a long time, the "Open" method of TOracleDataSet is raising Access violation with adrress 0.
The probable cause of this is that session is closed or connection lost.
However, when I close the connection by myself the normal exception is raised and I can handle it.
Still sometimes the AV happens.
After that the same method raises "Call in progress" exception several times, and then the normal "connection to DataBase lost" situation happens.
Is it possible to check the connection before each call to TOracleDataSet.Open or handle that situation in any other normal way?
(Because I think that AV from DOA is not a normal situation...)
 
Yes,
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bi
PL/SQL Release 10.2.0.3.0 - Production
CORE 10.2.0.3.0 Production
TNS for 64-bit Windows: Version 10.2.0.3.0 - Production
NLSRTL Version 10.2.0.3.0 - Production

And DOA is Version 4.0.7.1 (October 17, 2005) I think.
 
Today I tried using TOracleSession.CheckConnection just before opening the data set -- the test was ok, but the error still occured.
First there were "too many consequtive AVs" and then the exception was raised, which I mentioned above.
 
It seems like the problem has gone.
What was the cause? What does this boolean change?
When should it be set to false?
 
The Oracle 10.2 server has a bug that causes these access violations when parsed queries are reused. The boolean prevents that parsed queries are reused.
 
Interesting!

Any idea whether this could cause an application to terminate without any error messages (similar to using application.terminate)?

Reason I ask is our application on occasion seems to terminate of it's own accord, no error messages and this happens when the user has simply logged on - however there is a background process to check for messages every 30 seconds.

I've been trying to trace this for a number of months now but never thought of Oracle 10 - both customers reporting this are using Oracle 10g (10.2.0.1.0 and 10.2.0.2.0) and there doesn't seems to be any pattern to it.
 
I should have perhaps explained that the "process to check for messages" involves a dataset.refreshrecord and a dataset.refresh
 
Hello Marco,

Which specific bug are you talking about ?
Perhaps a bug in the "oparse" OCI call ?
Do you know the metalink id (if any) ?
Thanks
Bye
Nicola
 
Hi!

We have the same problem.
What can we do? What is the solution?

Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit
DOA:4.0.7.1

Thanks
 
  • Use the debugger to see where it fails.
  • Check if there are any event handlers for the dataset that could cause this.
  • Try it on a different PC to check if this is PC specific.
 
Back
Top