Reference for CrystalReports.Engine.ReportDocument object class

[mbenigni]

Hello, all.

I'm trying to build a simple VS2022 test application integrating the trial version of CR2020. There is effectively one line of code:

Dim CrystalReportSource1 As New CrystalDecisions.CrystalReports.Engine.ReportDocument

Which is returning an error:

BC30002 Type 'CrystalDecisions.CrystalReports.Engine.ReportDocument' is not defined.

I need to know what reference to add or Import in order to be able to use this ReportDocument object class (or an alternate object class name, if this has changed to something outside the CrystalDecisions namespace.) I've tried a number of Crystal Reports 14.0 references that looked promising but didn't help. And in previous (CR2008) versions of this same project I had successfully used the following Imports statements, but the targets are no longer found:

Imports CrystalDecisions.Shared
Imports CrystalDecisions.CrystalReports.Engine
Imports CrystalDecisions.ReportSource
Imports CrystalDecisions.CrystalReports.Engine.ReportDocument

Thanks in advance!

[mbenigni]

Apologies, I may have just answered this question myself. The following Imports appears to work:

Imports CrystalReportSourceLib

Allowing use of this new object class:

Dim CrystalReportSource1 As New CrystalReportSourceLib.PSReportFactory

I do have a follow up question, however. My project builds, but this line:

CrystalReportSource1.FileName = oFile.Name

Throws an exception at runtime:

Public member 'FileName' on type '_ComObject" not found.

I have been unable to find any documentation on the class hierarchy that's not already out of date. Can you provide any information on how to assign a filename to a CR2020 object in VB.NET?

Thank you!

[DonWilliams]

Hi Mark,

I hate this format, to many threads to follow, I like what every other Forum does, just post in a sequential stream so it's easier to follow the thread and whats been done.

OK, first thing is I don't suggest using the WPF viewer, it hasn't been developed as much as the Windows Form, and getting things fixed is tougher, it's not as robust as the Windows Form.

Open Connection is database client not being in the correct format, 32 or 64 bit, or if it's based on a PC type it tougher to find a 64 bit Client.

Uninstalling the 64 bit runtime doesn't patter at this point, it's the same one the EXE installs.

Single step through your app when you get to the database logon info and mouse over each collection and see what's missing in the collections/property bags.

Don

[mbenigni]

Hi Don,

I couldn't agree more about the non-sequential format of this page. For a couple of days I was convinced my comments were being deleted. 😮

I'm a little bit confused about your distinction between the WPF Viewer vs. Windows Form. My application is a VB.NET WPF Application, but I haven't explicitly added a form or a Viewer object; there is no report viewer or GUI at all. All of my code (and there isn't very much of it) runs at Application Startup and then the app closes.

I think your comment concerning bitness of the database client (data source is IBM DB2 via iAccess) may be relevant. We have both 32- and 64-bit versions of this driver installed. I assumed a 64-bit application would make use of the correct 64-bit driver, but perhaps this is not happening?

I can step through the code to a breakpoint and identify the line that throws the exception, but I'm not sure how to mouse over the collections relating to the database logon info to find missing properties. I'll keep working on this. Please let me know if you have any other thoughts in the meantime, and thanks again.

Best,
Marc

P.S. I made some progress this morning. I experimented with replacing ExportToDisk with Export, to no avail. Then I tried a different report with a different (MS SQL) data source, and that worked. Since I've had success with the IBM driver in the past, I have to assume the application is making the wrong connection (32-bit vs. 64-bit) via ODBC. Continuing to experiment.

[mbenigni]

Hello again. Based on your last response, and the progress I made this morning, I'm inclined to guess that my ODBC driver is the issue. As I said, we have both the 32-bit and 64-bit System DSN's established - but CR2020 Designer only exposes the 64-bit DSN. Is a 32-bit DSN required in order for a .NET 4.7.2 application to function properly with a CR2020 report? If anything, I would have expected 64-bit to be required.

Best,
Marc

[DonWilliams]

Hi Marc,

CR 2020 is a 64 bit application so it needs the 64 DSN,

In your application you also need to set the Project platform to x64 and x86 or AnyCPU.

When you do that the references should show being loaded from the CR x64 location.

Ans since you are not using the CR's WPF viewer that part doesn't matter now.

OK so you can't simply change the reports data source from MS SQL to DB2

You need to make the change in CR Designer itself and then save one for DB2 and one for MS SQL Server and use each report based on the data source. You can use ReplaceConnection() API to up the report in code if you want though but for now use different reports to simplify.

FYI - creating 32 and 64 bit DSN's using the same name allows the app to run in 32 bit mode, CR will find which ever one it needs.

Have a look at my upgrade Blog, it describes the differences.

So your next step is to figure out why the app is not finding the correct DSN.

My Parameter test app on the WIKI page should work for you, see if that works...

Don

[mbenigni]

Hi Don,

Yes, of course - I'd created two different reports, one for SQL and one for DB2, and changed the filenames and login information accordingly.

"FYI - creating 32 and 64 bit DSN's using the same name allows the app to run in 32 bit mode, CR will find which ever one it needs."

This is very interesting. I would have expected this to result in error, but I was able to change my 32-bit DSN name to match the 64-bit DSN name. At this point, the application ran successfully! This seems to imply that the application wants to reference the 32-bit DSN, which is counter-intuitive. I would have expected a CR2020 report to require the 64-bit DSN and driver. Does this make any sense to you?

I'll test further and work on completing this application. Thanks for the advice re: DSN names!

Best,
Marc