Error In Crystal Report: Memory full.

[N11689]

A user of ours is sporadically receiving the error message 'Error In Crystal Report: Memory full.' when running one of our distributed crystal reports in a runtime environment.

We have an application that uses a Visual Basic program to generate our reports.

We are using Crystal 9. I have seen many Memory Full errors on the Crystal websites and in this tech tips area, but nothing specifically seems to apply to the error we are receiving.

I need some help on this, and will be glad to provide you more information as needed.

 

[synapsevampire]

Some things to check:

-Local disk space
-Swap file size
-Connectivty is correct (if you use a CR ODBC driver and they use someone else's, you may have problems.
-All components are properly installed

-k

 

[vidru]

I've had the same problem on a VB project that was handed over to me, using VB6 and Crystal 8.5. The issue was traced to not dealing with the report objects after the report was generated, like:

Set cParam = Nothing
Set CrxRpt = Nothing
Set CrxApp = Nothing

-dave

 

[synapsevampire]

Good point, Dave, reset variables and you might even look at the memory of the box as it's going along, see what's loaded.

-k

 

[N11689]

What I'm going to do (to start) is have the users who receive this error reboot in the morning. I'm going to have them check their local disk space and swap file size/page file size (depending on operating system). Then when the error occurs again, before they press OK to continue, I'm going to have them check their local disk space and the swap file size/page file size at the time of the error.

We are using an OLE DB connection to SQL Server.

I believe all the components are installed correctly because they are able to print other reports fine.

I will check our VB program to see if we are setting the items = Nothing.

Will report back on this one as soon as I have more details.

Thanks very much.

 

[MColeman]

We got this same error on exporting a 42page report in version 8.5

We had to get a service pack to fix the problem.

Hope this helps!

 

[N11689]

Our user hasn't had the problem again (yet), but I am anticipating a call from them.

In the interim, I have a Windows 2000 machine SP2. I set the page file size down = to the RAM and ran our report. No memory full error. So, I am still having a problem duplicating it here.

I stepped through our VB program and we are definitely setting the App and Rpt to nothing after each printing of the report.

It's very hard to determine what the problme might be when I can't duplicate the problem, but I know our user has received the error more than once (but not consistently).
Thanks
Any other suggestions about what I might try?

 

[gregarican]

Our company is having a similar issue performing local printing using Crystal Reports RDC 8.5 called within a VB 6 app.

Details are in this thread-->

http://www.tek-tips.com/viewthread.cfm?spid=782&newpid=782&sqid=656365.

Just wondering how these issues out there are getting resolved...or are they??

 

[N11689]

Our user received the memory full error again (after nearly 2 1/2 weeks without it).

We had them send us print screens of their task manager Performance and Processes screens as they were at the time of the error.

It is definitely not the PC that is the problem. There is plenty of memory left.

It has got to be a Crystal issue or maybe our VB program that is causing this error.

We have used Crystal's 'Troubleshooting Tips for various types of memory errors' document. We found a similar scenario in there about using report APIs in VB produces an error. We looked at the resolution and looked at our code and we are doing what the resolution says.

This has now become a big issue and we are not any closer to resolving it. Can anyone offer any more suggestions?

Thank you.

 

[gregarican]

Here's a stab in the dark, but if you are encountering these errors on Windows 2000 workstations (especially those boxes that run 16-bit apps and have locally attached HP printers) it might be similar to what I finally figured out. Our printing errors weren't confined to Crystal Reports, as switching to native VB printing still resulted in sporadic errors.

Below is an excerpt of what I posted to an HP support forum. Just an FYI...

Just wanted to let folks know about issues my company has seen with the HPDCMON.DLL process conflicting with the NTVDM/WOW32 process under Windows 2000.

A 16-bit legacy app that runs in our environment has to load under the NTVDM/WOW32 process in order to function on our Windows 2000 workstations. Occasionally this process loads right next to the memory address block where the Win32 Language Monitor for Direct Connect HP Printers process is loaded (aka HPDCMON.DLL).

This situation has caused sporadic printing issues where users receive the message 'There was an error printing the document ***document name*** to LPT1:. Do you want to retry or cancel?' The users have to totally reboot to recover local printing functionality. They don't run into these issues when the 16-bit app hasn't been initially loaded at all.

Since the NTVDM/WOW process stays loaded even after the 16-bit app has been exited there were sporadic printing issues over time no matter if the 16-bit app was actually visible or not. This made it a bit tough to narrow down.

The only way that we were able to work around the issue was to disable the Win32 Language Monitor for Direct Connect HP Printers module.

Details on these points can be found in two Microsoft KB articles -->

http://support.microsoft.com/defaul...port/kb/articles/Q180/8/92.ASP&NoWebContent=1

and

http://support.microsoft.com/default.aspx?scid=kb;en-us;181333&Product=win2000

Hope this can help anyone else out there who is in the same situation as I was. It took about a month to figure out all of this from trial and error!

 

[N11689]

Our user received the error again. They sent us a backup of their data, and we were not able to duplicate the problem using the same exact data on the same operating system (tested on two different machines).

We have, however, discovered that the problem is DEFINITELY occurring in Crystal's PrintOutEx method.

We are printing the report to a file using Crystal's PrintOutEx method. We have created a log file via our VB program to write out exactly where the program is. It gets to the point in the program when it is about to execute Crystal's PrintOutEx method, and then the user gets the Memory Full error.

We are definitely destroying all objects before each call of PrintOutEx (we used Crystal's Memory error troubleshooting guide to check this, but we were already destroying the objects).

I have searched the Crystal knowledge base and Tek-Tips and all there seems to be are articles on how to use Crystal's PrintOutEx method. There isn't any information on memory issues.

Has anyone else experienced this problem? Does anyone have any ideas as to how to correct? Again, this is sporadic. It does not happen all the time. Does anyone know how the PrintOutEx method uses memory?

 

[gregarican]

I know the location of the CR printing object is important. In layman's terms if the object is created, used, and destroyed each print job or if the object exists on a more global scale. I believe it's better to employ the latter. Here's an e-mail excerpt from a third-party developer my company used to clean up our custom VB/CR app:

"I wanted to pass along the results of our investigation into Crystal Reports and its' intermittent failures during local printing. What we determined from our several days of trial & error is that under certain reproducible conditions, there were failures in the construction, initialization and/or destruction of the CRApplication object.

For us in C++, we created an object to manage the lifetime of the CRApplication. Essentially we create/initialize the CRApplication object (on Demand the first time the PrintManager is created (you could do the same in VB using a global instance to the CRApplication object versus defining one on demand within your VB modules/functions) once for the span of the session and we re-use it, never destroying the object until application shutdown (similar to globals but we frown on globals in our code reviews)."

What else I have noticed about VB apps is that if there are tons of files cluttering up the system's temporary folder sometimes report operations fail. That and general disk space issues that might fluctuate due to these aforementioned temporary files, temporary IE files, virtual swap files, etc. These environmental factors might make the difference between what other users are reporting versus what your experiences are.

Perhaps this makes more sense than the CR object's location...