TDataset Crash

[lecare039]

We are using DOA 4.0.6 in our application. It crashes "randomly" on a Terminal Server Windows 2003 Standard Edition. Oracle Monitors shows a red statement with "Access Violation at 0000.." and a response time. Server Event Log says, that there was an error in kernel32.dll procedure "SwitchToFiber". Oracle Server is 10gRel2 on an extra computer. Oracle Client is 9.2.

Is there a solve or is this a known problem?

 

[Marco Kalter]

Can you let me know the complete information of the Access Violation?

 

[Syspec]

We are using DOA 3.4.6.4 in an ISAPI dll (Intraweb - Delphi 7) on a Win2000 Server with IIS 5. Database Oracle 9.2.0.8 (on another server) and Client 9.2. We're also getting an Access violation at 0000 "randomly" when using a TOracleDataset on a DataModule (one datamodule for each user thread). I don't know what other information I can give about the AV because that's all we get. Pooling on the connection is spNone (we have one connection for each user thread - each user has a different login to the database). It happens when opening the dataset, but not at any specific time (just when there are a lot of users). I tried to get more information using DebugDiag but it seems that the debug symbols used with Delphi7 are not compatible.

This error only seems to have started occuring recently as the application was working without problems before.

Thanks,

Chris.

 

[Marco Kalter]

Can you set the Optimize property of the TOracleDataSets and TOracleQueries to False and try again? This problem may be caused by a 9.2.0.8 bug.

 

[Syspec]

Marco,

I changed the Optimize property to False and so far so good.

Can you tell me what the 9.2.0.8 bug is? This is so that I can explain why the application was crashing. It will do a lot to help improve confidence in the application (everyone was thinking it was the application that had the problem).

Thank you for your quick response (if all goes well it will have saved me a lot of grief),

Chris.

 

[Marco Kalter]

I don't have a bug number, but the problem can sometimes occur on 9.2.0.8 when reusing a parsed representation of a cursor. In other words: if a query is exuted twice without changing the SQL text.