Grouping is incorrect on 64-bit server

[Former Member]

I have a report that displays correctly in 32-bit development workstations and when run from a 32-bit server, but not on 64-bit servers.

This report displays responses to a survey that users have submitted. It has several levels of grouping, as follows:

Administration of the survey (an individual survey can be sent out multiple times; responses are grouped by each time they are sent out)

Response Date

Respondent

Response (the header for the set of answers that are submitted when the user clicks a Submit button on the survey)

Question Number (finally, responses to individual questions are grouped by question number; some questions can have multiple responses... think checkboxes, "choose all that apply")

The Question Number group is not handled correctly in the 64-bit environment. It will print the first few items under the first question correctly, then switch to the next question, and then revert back to the first question several times.

Like this:

1 Choose all that apply: Option 1

Option 2

Option 3

2 Question 2 Text ....

3 Question 3 Text ....

1 Choose all that apply: Option 4

1 Choose all that apply: Option 5

1 Choose all that apply: Option 6

It should be:

1 Choose all that apply: Option 1

Option 2

Option 3

Option 4

Option 5

Option 6

2 Question 2 Text ....

3 Question 3 Text ....

I can provide .jpg examples if it would be helpful.

We are using the Crystal Reports Basic Runtime for Visual Studio 2008 (x64) (files with version 10.5.0.1943). I tried installing the service pack version of the runtime (files with version 10.5.1.2285) but it did not affect the problem.

Any ideas on what the problem might be or a way to fix it? I also could not find anywhere to submit a bug report; is there someplace I should submit this other than the forum?

Thanks,

Casey Leichty

[Former Member · Accepted solution]

Hi, Casey;

We have seen this before. There is a note coming on this soon. The resolution from that note is:

Resolution

There are two possible solutions to this:

- Target the Project to (X86) runtime instead of Any Platform or (X64).

- Change the group order to Ascending or Descending.

Best Regards,

Jonathan

[Former Member · Accepted solution]

Thank you for your response. The question number group was sorted Ascending originally. I tried changing it to use original order and ensured that data coming from the database was in the correct order, but this didn't fix the problem. Following your suggestion, I also tried descending order, but still had the problem.

I don't fully understand what is necessary to target x86 instead of x64. Please excuse my ignorance... I have limited experience with both Crystal and 64-bit and have inherited several reports from a developer who is no longer with our company. Our .rpt files are all part of a single Visual Studio project. In the VS project's properties, on the Build tab under the General heading I changed Platform target from Any CPU to x86. This did not fix the problem, but I'm not confident I did everything that was necessary. As far as I can tell, we do not build this Visual Studio project and deploy any assemblies from it, and when I modify the .rpt files the changes are reflected immediately when I rerun the reports, so I'm wondering if changing the Platform Target on the VS project would be expected to have any effect. Perhaps I am misunderstanding your recommendation.

Thanks again,

~Casey Leichty

[Former Member · Accepted solution]

Hi, Casey;

After changing the project to run on x86, as you have done, it would need to be re-compilled, and then re-deployed to the 64 bit server. Has that step been done?

Regards,

Jonathan

[Former Member · Accepted solution]

Hello,

I figured out the source of my confusion. The Visual Studio project that contains the .rpt files does not get built and deployed with our application, so targeting it to 32-bit had no effect. We have a separate VS project that contains our ReportEngine class and references the Crystal assemblies (the reports are processed in an ASP.NET server application that hosts web services, and PDF files are passed to the client application). By changing this project to target 32-bit I was able to build, deploy, and run our application and the report rendered correctly.

A few other details that may be helpful to someone else who encounters a similar problem...

1) I had to install the 32-bit version of the Crystal runtime redistributables on the 64-bit server.

2) Because this is an ASP.NET application, ASP.NET on the server had to be configured to run in 32-bit mode. Otherwise, the w3wp.exe host process runs as a 64-bit process and is unable to load assemblies that are targeted for 32-bit. For details on how to accomplish this, see: http://support.microsoft.com/kb/894435/en-us .

3) After I figured out that 2) was necessary, I realized that I did not have to change my VS project to target 32-bit after all. If it is left targeting Any CPU, it will run as 32-bit when running in a 32-bit ASP.NET process, and will use the 32-bit Crystal runtime if present.

Thank you for your help in resolving this!

~Casey

Edited by: Casey Leichty on Apr 14, 2009 10:01 PM

[Former Member · Accepted solution]

Hello again,

Running our application in 32-bit is not an acceptable option, so I am exploring alternatives. One possibility is rewriting this report in an attempt to avoid the problem, but until we invest the effort we do not know for sure whether we will be able to get around the problem. You have acknowledged that this is a problem you are aware of... can you please give me some specifics regarding what the problem is and how it can be avoided? Before we invest more effort in attempting to rewrite the report, it would be helpful if you could give us some more information to determine whether it will be worth the effort and how best to target our efforts.

Some more details regarding what I have been able to figure out so far, or possibilities I've considered:

- Out of a dozen or so of our reports, this is the only one that has the problem. Of all our reports, this one has the most levels of grouping, so perhaps that is a factor.

- It only occurs in this report for certain subsets of data. I found that in some cases, if all the questions in a survey have question text that is limited to one or two lines when rendered in the report output, the grouping is handled correctly, but when I increase the question text to three lines the problem starts occurring. In other cases, it seems that when the Response group (see prior post for an explanation of the groups in this report) has enough questions that it extends to a second page, the problem starts to occur for that response or subsequent responses. Neither case seems entirely consistent, however.

- The data that feeds the report is normalized into multiple tables in a dataset. I wonder whether denormalizing the data into a single table of results would have any effect on how the report processes the groups.

Thanks,

~Casey Leichty

[Former Member]

Marking the question unanswered due to a followup question I have posted in the thread.

[former_member11696]

Hi Casey,

Your only option is to run in 32 bit mode and you MUST compile your app so it only runs in 32bit.

There is no other option and CR will not work nor is it supported to run with any 64bit flags turned on. Other than using the basic components that ship with Visual Studio .NET which is CR 10.2 or 10.5. But it is basic so you are limited in what DB drivers and export formats are available.

Hereu2019s a link that should explain it all:

https://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/10d5fa88-2013-2c10-c9a5-f1196360...

Thank you

Don