cancel
Showing results for 
Search instead for 
Did you mean: 

Issue with using crystal 8.5 and crystal 13 simultanously in dependent apps

Former Member
0 Kudos

Hello All,

I am facing some issue with different crystal versions used in applications. My application(let's say X13) is using crystal 13.0.10.1385 dotnet API and another application (let's say Y85) is using crystal 8.5 dotnet API version. My application X13 has a module which is dependent on application Y85 module and exchange information between them.


As both applications use crystal, CRPE32.dll is loaded in memory once for both the applications. The issue derives from the fact that the application X13 brings the crpe32.dll (version 13.0.10.1385) located in folder “C:\Program Files (x86)\SAP BusinessObjects\Crystal Reports for .NET Framework 4.0\Common\SAP BusinessObjects Enterprise XI 4.0\win32_x86” into memory. If the application X13 is not loaded into memory first then the version of crpe32.dll (i.e. 8.5.0.461) located in the application Y85 install folder will be used.


As we know that CR 13 and CR 8.5 are two entirely different API's now without any compatibility with each other. Now if my application X13 is initialized first and crpe32.dll (version 13.0.10.1385) is loaded in memory, on accessing the module dependent on application Y85, Y85 tries to make crystal calls.

It tries to call to PEOpenEngine, PEOpenPrintJob, PEGetNTables, PEGetNthTableLocation, crPEGetNthTableLogOnInfo and PEGetNDatabaseFields which executes fine but It is only the call to PEGetNthDatabaseFieldInfo that fails, with a return value of 0. Below is the sequence order of calls:


  1. A 2013 .NET Crystal Engine is initialized first using ReportDocument.Load method or CrystalEngine.CRPE.InitCrpe.
    1. Also note that calling CrystalEngine.CRPE.CloseCrpe has no positive effect of eliminating the issue.
  2. Subsequent calls to PEOpenEngine, PEOpenPrintJob, PEGetNTables, PEGetNthTableLocation, crPEGetNthTableLogOnInfo and PEGetNDatabaseFields all execute just fine.
  3. It is only the call to PEGetNthDatabaseFieldInfo that fails, with a return value of 0.

Question arises here is how to get PEGetNthDatabaseFieldInfo working when the .NET Crystal Engine has already been initialized.

  • Is there a separate declare we can add to our VB6 code that will be compatible with crpe32.dll version 13.0.10.1385?
  • Or can we load both crpe32.dll (version 13.0.10.1385 and 8.5.0.461) in parallel and instruct .NET crystal to use version 13 and other one to use version 8.5 dll?


I have attached a sample code demonstrating same too. It will be great if anyone can help me on this.


Crystal versions involved : 13.0.10.1385 and 8.5.0.461

Visual Studio 2012

VB.net

WIN APP



Thanks

Saurabh


Accepted Solutions (1)

Accepted Solutions (1)

0 Kudos

Hi Saurabh,

CR 8.5 never was side-by-side compatible with any other version of CR runtime.

And as of CR 9 you no longer are licensed to be able to use crpe32 as the reporting engine. R&D can change it at anytime so absolutely no support for it in that respect either. After CR 9 crpe32 was completely rewritten and a lot of parts were removed into their own dll's. The major parts were the DB drivers were renamed and the Parameter API's were also updated and old one's are no longer recognized, or may not work the same way.

So why not simply completely drop 8.5 since it is over 12 years old now... There is no reason you need to still be supporting it. We dropped support for it a long long time ago.

Don

Former Member
0 Kudos

Hi Don

I have upgraded my application X13 to latest crystal 13 but another application Y85 is another vendors  application. If it had been my app, I would have upgraded it too.

Any idea now how to proceed with it?

Saurabh

Answers (0)