Windows2000 and Citrix MetaFrame XP

[SMcNaughton]

What version of MFC42.DLL is on the machine?____Kathleen__R&R Support

[kfleming]

For those who might be interested, Steve and I emailed on this one and the source of the problem turned out to be a calculated field that used the CDLL()function. By repeatedly calling this function, the amount of memory was indeed diminishing. The solution was to pre-load the DLL on the command line. In the Report Designer you use the switch /D<dllname> and for runtime the switch is /AL<dllname>.____Kathleen__R&R Support

[Bob_Velke]

Kathleen,____Yes thank you very much. I haven^t stopped since we ^chatted^, but wanted to pass that info along here in the forum, logged in and saw you beat me to it :)____Now, here^s another question on technique:____Is there some way to make a second pass on the same result set without restarting the report scan? (Much the same way the designer seems to.) The reason is that I do a detailed report, say an A/R, then I just want the company totals and aging [extracted] on a separate sheet. If I re-scan, Users could make changes since my first pass and the results will not match...____1) I figure I could extract the data first in my application, then run the report (long process on some systems)__2) use the export function and use that result set to write another report aside from re-writing this one.____I was hoping for an option #3 :)____-Steve______

[kfleming]

Option 3 may be coming in the next release of R&R. But at this point it is only a maybe.____Kathleen__R&R Support

[Timothyglups]

Kathleen said:____>> For those who might be interested, Steve and I emailed on __>> this one and the source of the problem turned out to be __>> a calculated field that used the CDLL()function. By __>> repeatedly calling this function, the amount of memory __>> was indeed diminishing. The solution was to pre-load __>> the DLL on the command line. In the Report Designer you __>> use the switch /D<dllname> and for runtime the switch __>> is /AL<dllname>.____I don^t use the CDLL() function (because it has a 10-year-old bug). The only functions that I use in calculated fields are recno(), pageno(), inlist(), iif() and string functions. I see nearly 100% CPU consumption while merely sitting at a one-page Print Preview with no other applications running. If I start other applications, then their performance is severely degraded until I close the Print Preview. I have confirmed this behavior on no less five machines running Win95, 98, 2000, NT, and XP.____This is a serious problem! What can be done about it??____-Bob__

[kfleming]

This issue is being worked in development with a target to fix it in the upcoming Version 10 release (late summer/early fall).____Kathleen__R&R Support

[Timothyglups]

So it took 33 messages to finally confirm it is a bug ?

[Hamidtype]

Even before our web site had a support forum, we acknowledged this issue on our FAQ page.____Q) When I preview a report in either R&R or Arpeggio, I see 100% utilization of my CPU. Why is this happening? ____A) This problem is caused by a behavior in the software where a processing loop during preview is consuming all available CPU cycles. Processing large amounts of data is by nature a cycle-intensive process and even during print preview, R&R is deriving totals for display and dynamic updating. __In most environments, this issue will not impact users to any noticeable extent. However if users are running under NT Terminal Server and any Report Writer user is previewing a report, performance will degrade for all other users and applications on that Terminal Server. Until we are able to address this problem, the suggested workaround is to limit the use of print preview to active viewing of reports rather than allowing an unattended print preview window to remain open. Printing and exporting of a report do not exhibit the problem and may be a better alternative to preview in a Terminal Server environment.________Kathleen__R&R Support

[kfleming]

I don^t want to make a lot of noice about this but please read again your message no.7 again Kathleen. In that message you simply sort of deny the CPU consumption and at that time it would have been nice to confirm it is still a bug. It would save a lot of people a lot of time, money and frustration in trying to find a solution.

[Tom_W]

Kathleen,____As per your response .... Is this problem taken care of in Version 10?____Thank you____Tom