"Memory full." error while exporting report to PDF format - CR2008SP2

[Former Member]

<br>

Hello,<br>

<br>

I am developing a C#.NET application that uses the CR2008 SP2 .NET libraries. This application performs some database updates and uses CR2008 SP2 to run 7 different reports and export the results to PDF files. This application is a console application that only uses Crystal to export the rendered reports - it does not use previews or printing.<br>

<br>

The specific pattern of this application is as follows:<br>

<br>

- perform some database updates<br>

- render report #1 and export it as a PDF file<br>

- perform some database updates<br>

- render report #2 and export it as a PDF file<br>

... pattern repeats to report #7 ...<br>

<br>

This application works fine as long as I run only one instance of it at a time. The problem occurs when I try to run multiple instances of this application at the same time. When I run multiple instances of this application at the same time (against totally different databases) each instance will start up happily and begin running through the process described above. After a few moments one or more instances will fail during the report export. The specific error is as follows:<br>

<br>

"Memory full. Failed to export the report. Not enough memory for operation."<br>

<br>

The error always comes from the call to:<br>

<br>

CrystalDecisions.CrystalReports.Engine.ReportDocument.ExportToDisk(Format, FileName)<br>

<br>

I have watched the memory consumption of these instances of my application while they are running. They never seem to exceed approximately 52MB each. At this time task manager reports over 1GB of physical memory free. These numbers lead me to believe that memory is not actually "full".<br>

<br>

Here are some specifics about the environment:<br>

<br>

Dell Vostro 1720 / P8600 / 4GB<br>

Windows 7 Ultimate x64<br>

SQL Server 2008 SP1 x64<br>

Crystal Reports 2008 SP2<br>

<br>

Specifics about the C# application:<br>

<br>

IDE: Visual Studio 2008 SP1<br>

Type: Console Application<br>

Target platform: x86<br>

.NET Framework: 3.5 SP1<br>

Crystal References:<br>

- CrystalDecisions.CrystalReports.Engine (v12.0.2000.0)<br>

- CrystalDecisions.Shared (v12.0.2000.0)<br>

<br>

Specifics about the report templates:<br>

<br>

The report templates are RPT files saved from CR2008 SP2. They are relatively simple. A few of them (maybe 3) contain a single subreport.<br>

<br>

Specifics about the database:<br>

<br>

Each database is approximately 1GB in size. The database contains many tables but the reports only access a handful of tables. Each table that the reports access have maybe a few hundred rows tops. Most have less than 100. Likewise, when the reports perform their selections the resulting rowset for the reports is anywhere from about 20 records to a few hundred records tops.<br>

<br>

A few items to note:<br>

<br>

- Multiple instances of my application need to be able to run on a single machine at the same time. It is a specific design requirement.<br>

- My application works fine as long as I run only one instance of it at a time.<br>

- My application works fine when I run multiple instances if I comment out the Crystal part of it.<br>

- My application works fine when I run multiple instances if I change the export format from PDF to HTML32 or HTML40 (have not tried any others)<br>

- The machine has over 1GB of physical memory free when this error occurs.<br>

- I have taken steps to ensure that I am properly disposing of my CrystalDecisions.CrystalReports.Engine.ReportDocument instance just after each export is complete. I have tried to use the "using" keyword, as well as explicitly setting the instance to null and calling the .NET framework garbage collector. This did not seem to help.<br>

<br>

Any assistance with this issue would be greatly appreciated.<br>

<br>

Steve<br>

<br>

Edited by: scbraddy on Mar 11, 2010 1:53 AM

[Former Member · Accepted solution]

Hi, Steve;

It is hard to say what the problem could be. Some suggestions:

- What database are you using, and how is the report connected to it? Try a differnet database driver for the reports, and see if that helps

- What if you do not do the database update portion, do you still have the issue?

- Try installing Fix Pack 2.5 and see if it helps:

https://smpdl.sap-ag.de/~sapidp/012002523100002975192010E/cr2008fp25.exe

Regards,

Jonathan

Follow us on Twitter u2013 http://twitter.com/SAPCRNetSup

[former_member183750 · Accepted solution]

Couple of questions for you from me also and a suggestion. BTW.; wish everyone would construct their initial post as you have.

Question; are you using xml transforms? Reason I ask is that I have seen this error in that context only.

Suggestion. Base don the memory error, it may be that there is lots of memory available, but perhaps not one contiguous block of a sufficient size to process the report. E.g.; some sort of memory fragmentation? One way to test / alleviate this, may be to launch each report as it's own process (exe) and kill the process once the report is done(?).

Ludek

[Former Member · Accepted solution]

<br>

Jonathan & Ludek,<br>

<br>

Thanks for the timely response and good suggestions guys!<br>

<br>

I have performed a few more tests today in order to help answer some of your questions.<br>

<br>

Below are my responses. Some of them are answers to questions and some of them are observations based on tests I have performed today.<br>

<br>

- The database system is SQL Server 2008 SP1 Developer Edition x64.<br>

<br>

- The C# application connects to the database using the native .NET SQL client (System.Data.Sql).<br>

<br>

- During runtime I connect the report to the database by looping through the ReportDocument.Database.Tables collection. For each Table found I create a CrystalDecisions.Shared.TableLogOnInfo instance, fill in the table name, server name, database name, user ID, and password, and use Table.ApplyLogOnInfo() to apply it. I do the same thing for the subreports collection if there are any. Like I said, about half of the reports contain a single subreport.<br>

<br>

- The report templates are currently set to use the "SQLOLEDB" Provider. The Database Type is set to "OLE DB (ADO)". I am not entirely sure what you mean by trying a different database driver. I assume you mean to change the provider? If so, given the fact that we are using SQL Server 2008, what would I change it to?<br>

<br>

- If I do not perform the database updates during application runtime (instead, perform them ahead of time and then allow the application to only render the reports) then I still have the same problem. Nothing changes.<br>

<br>

- I installed the Fix Pack 2.5, rebooted, and tried again. Same problem.<br>

<br>

- I do not beleive that I am using XML transforms. How would I know?<br>

<br>

- Regarding fragmented memory: It is hard for me to believe that, given the amount of memory free on the machine once all processes are up and running (1GB+), and the size of the processes (~50MB), that a contiguous block could not be found. Maybe there is some Crystal process that is attempting to balloon out of control, but as far as I can tell my application is not getting very big. I will not rule this out of course because I don't know for sure.<br>

<br>

- Regarding killing the process once a report is rendered: The problem with this is that the application needs to perform these 7 groups of updates and render these 7 reports in a specific sequence all as part of one complete "pass". Also, this application needs to be able to be able to handle a scneario where one or more instance of the application is started on a single machine at roughly the same time (pointed at different databases). The application actually does work fine in this regard (staying well within the capabilities of my 4GB laptop even when 8 of them are running) except that I always get the same error when I choose PDF as my export format.<br>

<br>

- I ran a test today where I changed the export format to HTML40 and started 8 instances of the application at the same time, each working from a different copy of the database. The instances ran a little slow but did complete in good time with no errors. Please note that changing the export format to PDF will cause the application to fail with the "memory full" error if even only 2 instances are running at the same time. The only way I can successfully complete a run with the export format set to PDF is to run only 1 instance at a time. I can run it over and over all day long and it will not fail, as long as only 1 instance is running at a given time. As of yesterday I had only proven that the application would complete when using the HTML40 export format when 2 or 4 instances are running, but today I doubled it again (to 😎 and still no failure while using HTML40. This is possibly the most interesting fact about this problem, and is another reason why I am skeptical that memory fragmentation is the culprit.<br>

<br>

We would like to solve this problem because we would like to continue to target the PDF format. It is the standard report export format for our applications. If we cannot solve this problem we may call a meeting and decide whether to proceed with the HTML40 export format, or possibly dump Crystal from this project altogether.<br>

<br>

Thanks again for your interest in our problem and your timely and helpful responses. I'm really not sure where to go next ... maybe change the database provider in the templates? I will need some specific advice in this area because I'm not sure what to do. Any more ideas you guys have will be greatly appreciated on this end!<br>

<br>

Steve<br>

<br>

Edited by: scbraddy on Mar 12, 2010 2:18 AM

[Former Member · Accepted solution]

<br>

Jonathan & Ludek,<br>

<br>

I believe I have made a bit of a breakthrough on this issue. I found this post on a different forum:<br>

<br>

http://www.vbforums.com/showthread.php?t=491232<br>;

<br>

This led me to examine my Windows default printer. My default printer was set to a "Dell Color Laser 3010cn" that I have in my home office. I changed my default printer to the "Microsoft XPS Document Writer" and re-ran the same test with 8 instances. This time it seemed to complete without failure. I switched back and forth and re-ran the test many times and the relationship appears to be 100%.<br>

<br>

The original poster of that thread ("sebcia") seemed to think that the issue was related to the printer "no longer being in use", which I assume ultimately means that it was unavailable (offline). My Dell 3010cn may be online or offline, depending where I am working. I have another printer mounted "Ricoh Aficio 3035 PL6" which exists in our comany's office in California (I am in Tennessee). This printer may appear online or offline depending on whether I am connected to the company office via VPN.<br>

<br>

Long story short, my application works fine when the default printer is set to "Microsoft XPS Document Writer" or "Ricoh Aficio 3035 PL6" in the online or offline state, but never works when my default printer is set to "Dell Color Laser 3010cn" in the online or offline state. I ran the tests enough times to be fairly sure of the relationship between the default printer and the failure of the application.<br>

<br>

A summary of my test results:<br>

<br>

"Dell Color Laser 3010cn" = fails when ONLINE or OFFLINE<br>

"Microsoft XPS Document Writer" = succeeds when ONLINE, not sure if it is possible to make it OFFLINE<br>

"Ricoh Aficio 3035 PL6" = succeeds when ONLINE or OFFLINE<br>

<br>

Basically it appears that setting this particular Dell printer as the default printer in Windows will cause my application to fail when exporting in PDF format. I want to reiterate that I am not doing any printing or previewing in this application. I personally wrote every line of code in this application so I can say this with certainty. Also I want to add that this Dell 3010cn printer and printer driver appear to work fine - I use it all the time without trouble.<br>

<br>

My next questions are:<br>

<br>

- Is there anything about this revelation that sparks any new expalation or advice from you guys? Have you seen this before? Any idea what is going on here?<br>

<br>

- I would like to be able to make a change to my application to make it "immune" to the effects of changing the default Windows printer to a printer that the Crystal PDF export code doesn't "like". Do you have any suggestions? Maybe there is a method I can call or a property I can set that would negate the effect of the default printer selection in Windows allowing my PDF export to succeed in any case?<br>

<br>

As usual any advice or ideas are greatly appreciated on this end.<br>

<br>

Steve<br>

<br>

Edited by: scbraddy on Mar 15, 2010 4:40 PM

[former_member183750 · Accepted solution]

We could try a couple of options;

Enable "Dissasociate Formatting Page Size and Printer Page Size"

Enable "No Printer"

Both are under File | Page Setup.

Ludek

[Former Member · Accepted solution]

Ludek,<br>

<br>

Thanks for your suggestion. I enabled these two settings in my report templates and saved them. I was immediately able to run multiple instances of my application while targetting PDF and having the "Dell 3010cn" set as the windows default printer. After many runs the "out of memory" error has not occured again. It appears to work fine at this time on my development machine, and we are now moving this application into QA. This should allow us to confirm that this issue is clear.<br>

<br>

I would like to make you aware of one caveat though. At one point I switched back to the original templates (the templates that were causing the error originally and did not have your suggested changes) and they seem to work now! I was careful to confirm this finding.<br>

<br>

This is a very strange problem and I don't know what to make of all of these twists and turns, but we seem to be in good shape at the moment. Once the application has been through QA I will post the results in this thread. Thanks again for your help!<br>

<br>

Steve<br>

<br>

Edited by: scbraddy on Mar 31, 2010 1:37 AM