| Author |
Message |
brain
Newbie
Joined: 13 Apr 2010
Online Status: Offline
Posts: 36
|
   Topic: Very slow Crystal Reports on XP but not Windows 7
Posted: 23 Dec 2011 at 11:34am |
We recently upgraded a software package from DB2 9.5 to 9.7, replete with many, many DB updates and a set of updated front-end applications. The applications use Crystal Runtime XI to pull up reports germane to the context from which the report is called.
The software manufacturer supplies many Crystal Reports, and we have supplemented this with many of our own, developed in CR XI Pro.
As of this upgrade, several of our reports (transportation delivery manifests) open VERY slowly. The users' workflow is such that they run this report with one parameter (a delivery trip), then immediately with another (the next delivery trip), and so on for up to 20 repetitions.
On Windows XP Pro and Windows 2003 terminal server, the preview of the first one takes perhaps two seconds, three or four for the second, and up to two or three minutes by the time they get to the tenth one. The problem occurs immedately after they click the preview button to generate the report (i.e. not after the preview before sending output to the printer). It happens regardless of whether they actually send each report to the printer as they are previewed. I have already tried using alternate printer drivers, upgrading CR Runtime to SP2, both to no avail.
I discovered in testing that the problem is entirely absent on Windows 7 64-bit station (the two stations I had available for testing), so I have temporarily given the key users remote access to one of these stations just for running these reports until we can get this fixed. These reports run flawlessly there, without exception.
I cannot consistently duplicate the problem, even logging on to the users' workstations, but it is almost entirely consistent during their daily workflow.
This is seriously hampering our operations.
If I were to hazard a guess, I would think that something, perhaps in the application calling the report, is caching entries in memory and thus runs the reports much slower when the user has been using the application all day than when I log on remotely and go directly to printing manifests (where I can never seem to duplicate the issue).
Since we have a support contract with the software manufacturer, I have now a weeks-old trouble ticket trying to figure out what is happening. Currently, the focus is on our specific reports. While, I will be the first to admit that could be the case, there seems to be no explanation why that same report would run flawlessly on Windows 7 or why we cannot consistently duplicate the problem.
I am posting here just in the hopes that someone may have encountered similar behavior before.
|
 IP Logged |
|
|
asam
Newbie
Joined: 08 Jan 2011
Online Status: Offline
Posts: 20
|
Posted: 25 Dec 2011 at 2:16pm |
Software packages like you are using can be challenging. (I am currently dying with one called "Labtech"! Have you thought of revising your report(s) to group on (delievery trips) rather than running a separtate report for each trip? My thinking here is that perhaps your software is saving the data each time you run the report and by the tenth time Crystal is choking on it!
Edited by asam - 25 Dec 2011 at 2:17pm
|
|
IP Logged |
|
brain
Newbie
Joined: 13 Apr 2010
Online Status: Offline
Posts: 36
|
Posted: 26 Dec 2011 at 6:19am |
Grouping is not really an option here. We have hundreds of trips, and users print them one at a time using different report formats.
I agree, though, that it appears that Crystal is retaining the information between jobs, and the question is why.
Even that, though, does not explain why there would be such a stark difference between Windows XP/2003 and Windows 7. It could just be the difference in the processor and available RAM, since the Windows 7 stations are newer; however, I find the difference between three seconds and two minutes too great a difference to fully explain this, so I assume there must be something in Crystal Runtime that is responding differently on a 32-bit OS from the 64-bit Windows 7.
Edited by brain - 26 Dec 2011 at 6:19am
|
|
IP Logged |
|
asam
Newbie
Joined: 08 Jan 2011
Online Status: Offline
Posts: 20
|
Posted: 26 Dec 2011 at 9:38am |
This idea might be sort of far out thought but - - Have you got "File ->Options->Reporting" checkbox "Save Data with Report" checked?
|
|
IP Logged |
|
brain
Newbie
Joined: 13 Apr 2010
Online Status: Offline
Posts: 36
|
Posted: 26 Dec 2011 at 10:14am |
Good thought, and that option is checked; however, that specfic option is the default for new reports, not the effective setting for the current report. The actual option for the current report is under File -> Save Data With Report, and it is unchecked.
Again, there is no indication why these particular reports run flawlessly under Windows 7 but display extreme latency under Windows XP.
Edited by brain - 26 Dec 2011 at 10:14am
|
|
IP Logged |
|
lockwelle
Moderator
Joined: 21 Dec 2007
Online Status: Offline
Posts: 4372
|
Posted: 27 Dec 2011 at 3:38am |
does the problem continue if your users log out of application and shut the application down and then restart? It might not be the operating system per se, it might just be how Windows 7 handles 32 bit programs is different/more efficient at releasing resources. If shutting down the application and restarting it works, then you know it is something in how the application is handling the reports (and is probably operating system independent), and gives you a work around that your users could log out at lunch and/or breaks. HTH
|
|
IP Logged |
|
brain
Newbie
Joined: 13 Apr 2010
Online Status: Offline
Posts: 36
|
Posted: 27 Dec 2011 at 5:34am |
This is pretty much my line of thinking, since there is definitely an OS-related component here.
This was one of the first things the user tried. He rebooted his computer and started again. Within several iterations of the report, it was back to running these reports slowly. However, in another test some days later, I had him close the application and re-open it, and then the reports ran fine for many iterations.
Although I have not therefore been able to establish an absolute link between restart and better performance, it does appear to have some effect. We may be able to use the workaround of running these reports after application close/reopen or computer logoff/logon, but workarounds are never entirely satisfactory to me.
If there is a problem with the 32-bit application running on 64-bit OS, then I think the software manufacturer needs to deal with this for a long-term fix. None of our other applications exhibit this degradation of performance, even when performing repetitive tasks; I just cannot tell whether it is Crystal Reports runtime or the application calling it that is responsible for the latency.
Besides that, this was not an issue until our recent upgrade, so it all seems to point to an OS-dependent application-specific performance issue. Having said that, when this happened on our Windows 2003 terminal server, I checked the processor utilization, and during the period of high latency with the report, the calling application was consuming 50% or more of the processor.
Even seeing that does not help, because Crystal XI runtime does not appear as a separate application in the Task Manager, so I still cannot tell whether it is the calling application or CR runtime that is responsible.
I was just hoping someone else had seen this behavior in Crystal and there would be a known fix.
|
|
IP Logged |
|
lockwelle
Moderator
Joined: 21 Dec 2007
Online Status: Offline
Posts: 4372
|
Posted: 27 Dec 2011 at 6:01am |
the next question that pops to mind is, are the affected reports canned (built in reports) affected the same way, or is just the ones that you have written? could be that the application handles the reports differently (you wouldn't think so, but it may be...for our customer created Crystal Reports we actually have a different app that runs them...not ideal, but it is what we have inherited)
|
|
IP Logged |
|
brain
Newbie
Joined: 13 Apr 2010
Online Status: Offline
Posts: 36
|
Posted: 27 Dec 2011 at 6:38am |
We have been considering this, and our software vendor assumes this, since their stock report runs just fine. However, their stock report falls far short of the complexities we require on our report, and our custom reports all ran fine before the upgrade.
The software manufacturer allows great flexibility this way, however, allowing us to run any report--canned or custom--from almost any context in their application. In this case, the program context just hands a parameter (the trip number) to the report.
Still, I am left with these three central and very important facts:
1. These reports all ran fine on all OS configurations before our recent upgrade of DB2 and their program EXEs.
2. They all run fine on Windows 7, but not on XP/2003.
3. I am virtually unable to reproduce the problem in testing. Since I log on fresh and begin testing, rather than working in the application for hours before running reports, it is possible that I am not duplicating the sequence of events required to trigger the issue. This would point to an issue with CR runtime or the application calling it not releasing memory (or processor threads) correctly on Windows XP.
|
|
IP Logged |
|
asam
Newbie
Joined: 08 Jan 2011
Online Status: Offline
Posts: 20
|
Posted: 28 Dec 2011 at 4:09am |
Just for what it may be worth - - -:
I had a memory/performance issue with a report server application that was done in Visual Studio.
That application was designed intentionally so that Users could pull up multiple reports concurrently
and even multiple instances of the same report. User could look a one, then the next then the first, etc.
User could mouse click to close one or all and then go on doing something else in the app.
Problem was the app was just using the mouse click to call a dispose method for the Report Viewer.
It closed the Report Viewer but the Report Documant lived on!!
After I added code to specifically close the Report Document as well as the Report Viewer,
memory health was restored. As Lockwelle suggested, Win 7 may do a better job of auto-disposing than XP.
Edited by asam - 28 Dec 2011 at 4:11am
|
|
IP Logged |
|
|
|
