Crystal RDC causes GPF on PB disconnect 1

[everkleer]

I am using PB with the Crystal RDC. I have an app that conects to a db in pb then, among other things, can use the crystal rdc to view reports, then when the user is done it obviously disconnects from the db in pb. My problem is that the program crashes when I try to disconnect and I have tracked the source of this bug to be in the crystal commands. For one thing, if I try to open a crystal 9 report (using the crystal 9 rdc), I will get the bug when I disconnect whereas I don't if the report was created in a previous version of Crystal. Also no matter what version the report is in, if the report takes parameters and I enter one (either programatically or manually through the prompt that appears when I try to preview the report in the reportviewer control), I get this disconnect bug. And when I use the crystal applictaion ole object functions LogOnServer(...) or LogOffServer(...), I also get the GPF when disconnecting in PB.

I am using PB9 (also tested with the same results in PB8), Oracle 9i DB (also occurs w/ 8i), and, as I said, Crystal 9. Any help would be greatly appreciated!

Dan

 

[xsyguy]

I had a similar problem with a DLL that was making its own connection to the database. (I assume Crystal RDC does this as well.) Our solution was to add "ThreadSafe='yes'" to the DBParms property in the Transaction object in PowerBuilder before connecting to the database.

I don't know for sure that your problem is caused by multiple connections to the database, but it's worth a shot.

Good luck,

 

[everkleer]

Thanks, I've spent days trying to find a solution for this and that worked. However, in the PB documentation it mentions that using threadsafe can hurt performance. Do you know how it affects performance or where I might be able to read more on this?

Thanks again,
Dan

 

[xsyguy]

ThreadSafe='yes' envokes a special set of threadsafe routines in the Oracle Client. As I understand it, these routines do additional testing during all database transactions for potential conflicts with other connections (threads) running on the same machine. The additional testing obviously takes each transaction slightly longer to execute and, if a conflict is found with another thread, a transaction may get suspended briefly until the other thread finishes.

If you rarely have multiple connections open simultaneously, the extra testing for every transaction is useless most of the time, but in our application I have not noticed any performance difference. The Oracle documentation should have more details about the potential performace differences between the "regular" client routines and the threadsafe routines.