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...)

Can you let me know your exact Oracle Server version, and your exact Direct Oracle Access version?

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.

Can you set the NoQueryOptimize boolean in the Oracle unit to True at run-time and try again?

Yes, ok.
I'll tell you the result as soon as the error occurs again.

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