0

There's an issue with the way reports are being generated. The reports are generated through Crystal Reports 8.5 with parameters passed through an application developed in Clarion 6.3

The problem is that the first time the report is generated (client balance, for example) it's generated correctly: the amounts all show up with their respective decimal places according to the Crystal .rpt file. If this report is then exported to Excel via the Crystal interface (Export button), and then re-generated it shows up without the respective decimal places.

I haven't been able to replicate this behavior locally (running Windows 8.1, Crystal Reports 8.5, MS Excel 2013, SQL Server 2008-R2) but I have confirmed this behavior on a client's server, where the application and CR8.5 are installed. One difference I've noticed is that they're running MS Excel 2016, but haven't been able to establish a correlation to the presented behavior.

Has anyone else run into this type of problem before, or have heard of someone who has run into this? This has only been confirmed with two clients, both running the application and reporting tool on Windows Server 2012, the rest haven't seen this type of behavior while generating reports (any report that contains decimal places).

EDIT:

The first time the report is generated everything shows up fine, but if the report is then exported, to any other format (Excel, PDF, etc.) the subsequent "generations" have the decimals at .00 in the Crystal preview and the Excel or PDF export, even if previously they showed some value. NOTE: This behavior has been shown to happen only when connected via remote desktop. If the report is generated/exported on a local machine (laptop, workstation) this type of behavior cannot be replicated.

Omar De La Torre
  • 1
  • 2

2 Answers2

0

Are you saying that the decimals do not show up in Excel? Or that they show up in the preview in Crystal, show up in the Excel export, but when the preview is re-run after exporting to Excel they do not show up in the preview the second time?

Either way, Crystal Reports 8.5 is 16 years old according to: https://en.wikipedia.org/wiki/Crystal_Reports

I can tell you that on CR11 this is not an issue I have experienced. Do you have the ability/license to update your software? Try updating your software and see if that solves your problem.

Jackson
  • 217
  • 1
  • 15
  • The first time the report is generated everything shows up fine, but if the report is then exported, to any other format (Excel, PDF, etc.) the subsequent "generations" have the decimals at .00 in the Crystal preview and the Excel or PDF export, even if previously they showed some value. NOTE: This behavior has been shown to happen only when connected via remote desktop. If the report is generated/exported on a local machine (laptop, workstation) this type of behavior cannot be replicated. – Omar De La Torre Oct 03 '17 at 14:24
  • I would copy/paste your comment here into your question to add the clarifcations permanently. The info about it only being an issue when running the software via RDP is new and helpful. – Jackson Oct 03 '17 at 17:33
  • I would still recommend updating your software and expect that they've addressed some RDP issues since the year 2001, but I'll see if I can spoof an RDP tomorrow back to my local box and replicate your issue in CR11. – Jackson Oct 03 '17 at 17:34
0

Thanks for the help, Jackson. At this time the client isn't able to upgrade to CR11, for some reason that they didn't quite specify, but I was able to identify the cause of the issue.

For some reason that I haven't been able to fully identify, the region of the machine comes into play. As I mentioned that the issue presents itself while accessing the application via Remote Desktop, if there is a difference between the region configuration on the host and remote machine, the decimals will reset to zero upon subsequent report generations. If the machines coincide in the region configuration, this doesn't happen.

I will still attempt to persuade the client to upgrade the reporting software and see if this issue is still present. Will do some local tests and research on the matter as well to determine if this deserves a ticket with SAP/BusinessObjects.

Omar De La Torre
  • 1
  • 2