views:

204

answers:

1

We have a VB6 application that can generate reports using the Crystal Reports 8.5 runtime. To generate one of the more complicated reports we have, the VB app does the following:

  1. Deletes records from a SQL table (we'll call it Foo) based on the session ID of the user
  2. Performs a select statement, and populates the Foo table with the contents of the select statement.
  3. Massages the data in Foo.
  4. Executes the report (we'll call it Bar). The Bar report uses the Foo table as part of some outer joins to get some descriptions.
  5. After the report is opened and populated, the code then deletes the records in Foo.

If you ever look in Foo there will be no data since it is always purged at the end, but the Crystal Report will still have the data, since Foo wasn't cleared out until after the report ran.

Most sites can export this report afterwards, to either PDF or Excel, with no issue. One site, however, has two servers in production where if you attempt to export the Bar report (doesn't matter what format it is exported to), the report will visibly refresh and then export the report in the requested format. This refresh, however, causes the exported data to be invalid because the report is still doing the outer joins to the Foo table, which is now empty.

I'm at a total loss why the report refreshes before printing on these two servers. One server has Crystal Reports 8.5 installed on it as well as the Crystal Reports 8.5 runtime (so they can modify reports). The other server only has the Crystal Reports 8.5 runtime (so you can generate reports from the VB application, but can't modify them on that server). Both of the servers belong to a French site.

Another support staff here said the issue sounded vaguely familiar to an issue a few years ago, and suggested re-registering DLLs. I have tried unregistering and re-registering the following DLLs out of frustration:

Crystl32.ocx
crxlat32.dll
cpeau32.dll
exportmodeller.dll
crtslv.dll
atl.dll

Unregistering and re-registering the above DLLs does not fix the issue.

If we take the problem report, and run it on any of our development or QA servers, we have no issues; the report does NOT refresh before exporting, and the data looks consistent.

It seems like a server or regional setting may be causing this, but what could possibly cause the report to refresh before exporting on only two of our servers?

The most obvious solution is to simply alter the code so the Foo table isn't purged after the report is run, only when the report is run, but this is a production issue, the customer wants a fix now, and there's quite a few hoops to jump through to make the change.

A: 

One of our developers decided on a lark to simply copy the report from one of our test environments back onto the live sites with the issue, and the reports have suddenly started working again... they no longer refresh when exporting, and behave as expected. Truly bizarre.

LittleBobbyTables