Why does a deployed report need local database connection?

[PManion]

My company has an application that uses MS SQL Server as the database, and Crystal Reports 8.5 as the report engine. I am having difficulty debugging CR problems in this application and I could use some help.

Ideally I would like the user of an application to select a SQL Server datasource, including server name and database name, upon opening the program and have the program connect to the database. Naturally I would like the reports to access this same database. But although the program has no problem accessing SQL Server data, it seems to have the hardest time getting the reports to open reliably. Very often, a report will open flawlessly on my test computer, but when it is redeployed to a new user's machine, the report will fail to open. The most common error is "Server has not yet been opened".

Since I am relatively new to CR, I am trying to understand the rationale for including local database server connection information inside the report files themselves. Whenever I manipulate a report in CR and save it, the default behavior is to save this local connection data in the report file. I see no point in distributing a report to an end user that contains references to my local database server connection.

So, as I understand it, either this information needs to be stripped out of the report before it is deployed, or it needs to be overwritten by the local user's correct database connection information during the program run. In either case it should have the correct connection before the report is opened and displayed.

The program itself is written in Delphi 5; it uses the RDCReport, RDCApplication, and CRViewer ActiveX controls to handle the report connection.

 

[FVTrainer]

Well, I can't talk to your specific environment (Delphi), but I can confirm that you need to pass database connectivity info at runtime, after creating the Report but prior to calling the viewer. Or, you can create an ADO recordset in Delphi and pass it to your report (at least I would assume so since there's a KB article on it at the Crystal Website:

http://support.crystaldecisions.com/communityCS/FilesAndUpdates/SCR8_Delphi_RDC_ADO.exe.asp).

This is actually the approach I would recommend to anybody building an app against SQL Server data. The only difference from the example Crystal provides (the above link) and the way I would recommend doing it is that Crystal always shows using the Active Data driver with ttx files. This approach is perfect if you, as the report designer, don't have access to a sample database when you are developing the report. But it sounds like you very much do have access to a dev database, so I would recommend that you create your reports using the Active Data Driver (ADO) option that is available to you in the Data Explorer (Active Data is found under "More Data Sources" in CR 8.5). After choosing this option, you define the connection and a SQL statement that provides the resultset your report will use. Then at runtime, your vb app will pass any identical, in terms of schema, resultset to the report. The report has absolutely no connectivity to the database. It simply receives a recordset from your app. It makes deployment very easy. No more connectivity problems.

The downside is that modifying existing reports that have multiple tables to use an ADO datasource can be a very big pain, because you end up losing many, if not all, of the fields from the report layout.

You might also want to look at the sample RDC apps in this document:

http://support.crystaldecisions.com/communityCS/TechnicalPapers/apps_delphi.pdf