Crystal Reports HUGE unsolved memory leak!

[Former Member]

So I read this thread:

I consider that thread unsolved, I tried all of the things mentioned in that post and nothing! I still have that exact situation with that exact problem.

I had an MDI Parent and an MDI Child, the child form has the report viewer on it. Everytime I call that child window, new or already run report my app grows by at least 20,000k. After I close the window (I do all the disposes and closes) it sheds about 300k but thats it. I have tried everything I can think of and between myself and 2 other engineers here we have narrowed this down to the Crystal Runtime.

Ideas/thoughts/REAL solutions welcome.

[former_member183750 · Accepted solution]

Hmm. Not sure why this would not be considered solved? The text of the last post on that thread:

I added GC.Collect(); before, I donu2019t know why it is working now (or why it didnu2019t work then.)

but GC.Collect(); works!

Thank You!

Looks to be solved to me. A "real" solution(?).

Ludek

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

Got Enhancement ideas? Try the [SAP Idea Place|https://ideas.sap.com/community/products_and_solutions/crystalreports]

[Former Member · Accepted solution]

So because it worked on one computer one time its a solution?

That doesnt work for my app so therefor no solution for me.

Also calling GC.Collect() is not recommended by MS... They say you should let the system do what it is deigned to do. That is there for when you implement IDisposeable.

So again no solution.

[former_member183750 · Accepted solution]

So because it worked on one computer one time its a solution?

- In the absence of contrary data (until now), yes that would constitute a solution...

In any case, at this point, you have the following options;

1) Make sure you are using the latest Service Pack for your version of Crystal Reports

2) Create phone case and discuss the issue with an engineer who can try to duplicate it. If this is a bug, he will report it for a fix and your case will be refunded.

3) Wait and see if someone on the forums wants to test it for you (I'm gone for two week starting Thursday)

Please note that these are only forums, not support. For details, see the blog [What are these 'support' forums good for anyhow?|].

- Ludek

[former_member11696 · Accepted solution]

How simple are your reports?

Try no DB and just a text object, check everything off, no Printer etc.

Are you threading in your app?

Create a simplified app that duplciates the issue when you log the case, the easier to duplicate the quicker the Developers can trace into the issue.

Don

[Former Member · Accepted solution]

Varying degrees of reports. Simple to Not so simple. Whats funny is that depending on the report is the degree of mem leak. All of these use a SQL ADO connection for what its worth. I do dispose of that after the report is disposed.

When you say threading what do you mean? It is a .net app and its MDI so it would use apartment model threading by default unless you are suggesting some other type of threading??

[former_member11696 · Accepted solution]

Can you hit the DB directly and duplicate the issue, to see if ADO.NET driver is the cause? Could be it's leaving something open even though you are closing/disposing. Datasets are memory hogs because CR can't access the original source we have to copy the data, MS security thingy...

Just wanted to make sure you were not calling a Report Processing dll in the backend that threads the report jobs.

Thanks

Don

[Former Member · Accepted solution]

What do you mean by hit the DB directly?

[former_member11696 · Accepted solution]

Use OLE DB or ODBC connection to any database. Or if need be use our Extrame sample reports:

https://smpdl.sap-ag.de/~sapidp/012002523100005852352008E/cr_xi_xtreme_rep_smpl_en.zip

Don't use Ado.NET ( XML ) driver as your source db driver.

[Former Member · Accepted solution]

I am sorry, my mistake. I am already using OLE DB (ADO).