Hi, this is a strange one. Perhaps the worst part is that the issue doesn't occur 100% of the time. In the last hour, I've been able to run the report successfully about 30% of the time. Sometimes it runs correctly 3 times in a row, sometimes it fails 7 times in a row. There appears to be no pattern.

When the report runs to screen, I see the top bar fill out - the number of records (N of M) is shown. The page legend is filled out correctly. It appears that the database call has finished but I get nothing except a white screen. It locks the system and I get "Not Responding" and have to End Task. When I watch the processor through Task Manager, the CPU usage spikes and then drops off as the white screen hangs the system. If I set the report destination to the printer, it also freezes with the CR printing dialog displayed.

I have the exact same version of the software (with all the same Crystal dependency files distributed) at 25 locations and this only occurs at one location.

Technical Info:
Crystal Reports 8.0
ActiveX method, OCX embedded in Visual Basic 6 forms
MS Access 97 database

System: 3.00 GHz, 1 GB RAM (2x 512) Dell system, 60 GB free on harddisk, PageFile set to 1532 MB but the physical memory is never even close to maxed out by the report. The system has had no upgrades and came from the factory as described.
OS: Windows XP SP 2

i have this EXACT same issue, only this is a much smaller sample size (1 in about 2000 workstations)

sadly, these 2 workstations are ni the same office, and prevent my customers from printing on a regular basis.

does anyone know of a solution to this issue?

I've got the same thing. I have 2 machines that freeze while others are unaffected. Tried everything in comparing two machines to find any real differences. Could not find any. We are using Crystal 8. Problem is not sure if this is related to Crystal or with the machines themselves.

I am also facng this problem.

I found out in the code it is always on the

rptControl.Action = 1

The bad thing is that it is Crystal Reports that handling it. So I have no way of finding out what is causing it. As the others have said its not all the time, but with one of my customers it is about once out of 3 tries.

In our case we use the .printout instead of the .action, however the results are the same.
Testing it over 2 network stations, 1 'test machine' and 1 laptop over a wireless network connection, found that the machines that had trouble printing had 1 GB of RAM or better. The machines less than 1GB (the test machine and laptop) did not experience any problems. In your case, do the problem stations have RAM of 1GB or better? What really gets frustrating is that I the can't get the lower level machines (test machine and laptop) to fail. They all ran the same reports, using the same application, same o/s and same network database. The other half of the problem (I am not convinced it is a memory issue) is that I am not sure what to check next.