Stability difference between v4.0.0 and v4.0.7?

[E. van der Poll]

For one of our products we recently upgraded the direct oracle version from v4.0.0 (binaries) to the v4.0.7.1 (source version) we already had in use for some newer products, because of a bug which has already been fixed in that version. We found a problem with stability of the product.

The application displays a form with management info which is refreshed every minute. After several refreshes there follows an access violation. The version with the older DOA version does not have this problem. Also, the problem occurs only with one Oracle server, which is known to have a timeout problem.

The call in which the access violation occurs is according to the call stack TOracleDataSet.InternalOpen, which then calls TOracleQuery.Execute, etcetera. The exception occurs in oran9.dll (probably in procedure nsrdr) which is called from the DOA method TOracleFieldInfoList.GetFieldInfo.

Is this a known problem and if so do you known any solution or workaround? If necessary I can send you the full call stack starting from the internalopen call (from EurekaLog).

 

[Marco Kalter]

It is not a known problem. Note that Direct Oracle Access does not directly call the oran9.dll library. This is an internal Oracle Net library, which may indicate an Oracle Net issue.

If possible, do a test from a different machine and/or a different Oracle Net installation.

 

[E. van der Poll]

When executed from another PC the problem does not occur. The problem occurs only from one specific PC, in combination with one specific database server. It is fully reproducable, but does not occurs the first few times the information is refreshed.

It always occurs during execution of the same select statement. This is one of two queries in the refreshing code, and one which on this PC has already been executed several times before with the same OCI parameters. We checked with the oracle monitor, and the statements and the OCI parameters used are correct. The Oracle monitor only mentions that an access violation occurs accessing a nil pointer.

 

[E. van der Poll]

So far we have the following critical factors:
- the problem occurs with Direct Oracle Access v4.0.7.1 but not with v4.0.0.
- so far the problem has been reproduced only with a oracle client 9.2 and not with 8.1 (we have no machine with oracle client 10 available for testing as yet).
- so far the problem has only been reproduced on one oracle 10g server, and never on an oracle 9.2 server. we still have to test on another oracle 10g server to confirm this.

 

[Marco Kalter]

Perhaps you can send me the EurekaLog call stack?

 

[E. van der Poll]

By now we have also tested with another oracle 10g server. We found that the problems only started to occur once certain background jobs were active.

We have tested with both a 9.2.0.1 clientand a 9.2.0.7 client, with the same result. When testing with an oracle 8.1 or oracle 10 client we did not see the problem, so there is a specific mismatch between 9.2 client and 10g server.

Since I cannot attach information as separate files to this post I will send the callstack information separately by email.

 

[E. van der Poll]

Received your reply by email communication:

"This is actually an Oracle 10.2 bug when re-executing a query. This bug was later backported to 10.1 and 9.2 patch releases. To work around the issue, set the global variable Oracle.NoQueryOptimize to True before making a connection to the database. This setting will be the default in the upcoming 4.1 release."

I tried this and it seems to solve the problem. So far the application keeps refreshing the data without exceptions. Thanks!