Do ASP.NET crystal reports support background processing

[Former Member]

CR reports take too much of processing time for our web app. I have modified the process to generate reports in the background using ASP.NET asynchronus pages concept (http://msdn.microsoft.com/en-us/magazine/cc163725.aspx)

But now, the reports do NOT render at all. This makes me wonder whether they support background processing at all.

[former_member11696 · Accepted solution]

Hello,

Not a lot to go on here. See this thread for more info on threading:

As long as you are managing the threads and pointers it could work. Bottom line is CR works under the STA model.

Thank you

Don

[Former Member · Accepted solution]

Hi Don, thanks for replying.

I studied that entire thread, and unfortunately, could not find something that would work for me. For the specific comment you posted, I searched for GUID cb352f5b-7dbe-446c-a949-df925b6f6068 in the registry but could not find it, so could not switch the threading model to STA.

I am running VS 2008 SP 1 with the CR engine that ships with it.

Also, Here's are the various things I have tried:

1) Default.aspx has a CrystalReportViewer control.

I created a Report Source object in Init event, and set the Viewer's ReportSource property. Then in Load event, started a new background thread, releasing the front-end UI ASP.NET thread.

I sat the Report parameters and the Report Biding in the background thread, but the Report renders and asks for parameters again. This should not be happening as I have set all parameters in background thread, and they work without threading.

2) Default.aspx has a CrystalReportViewer control.

I started a new background thread (tried in both Init & Load events) releasing the UI thread, created the ReportSource in the background thread, assign it to Viewer, set parameters and bind.

The Report gives "Error: Program Error" when rendered.

2) Default.aspx is emptry.

I started a new background thread (tried in both Init & Load events) releasing the UI thread.

First created the viewer in background thread, then created the ReportSource in the background thread, assign it to Viewer, set parameters and bind.

The Report again gives "Error: Program Error" when rendered.

I have tried all options I could see of moving work to background thread, but as soon as I do so, Viewer fails for some reason.

[former_member200290 · Accepted solution]

Hi,

I have not done any threading in a web application. However I have with a win form application. Our object can work with both STA and MTA applications, however in a MTA application a single ReportDocument object must be contained in a single thread.

What does this mean? Here are two scenerios:

Export/Printing: Main thread creates a secondary thread. The secondary thread creates a new report object, loads a report, sets any properties needed then exports the report. Secondary thread exits.

In this case the report is contained in the secondary thread and everything is fine.

Viewing on an MDI child form: The way to do this would be to create the secondary thread. The secondary thread creates a winform control. The winform control has our viewer control on it. The winform also creates a report object which it passes to the viewer control.

In this case a the report is contained in the child thread still. But it does require a child winform to work.

Viewing on the same form, but report is generated in thread: This is tricky because be default you cannot pass the report between threads. So if you had this in a single form what you would need to do is a hybrid approach. You would need to follow the export method above, exporting to Crystal Reports format, and then when the secondary thread completes then that triggers an event in the main form(thread) to load the generated report.

Now when this comes to ASP .NET, I am not sure these methods are going to work, except for maybe have the report process in a secondary webform like a non-modal pop-up.

Not sure if this helps too much but maybe it will clear things up.

Trevor

[Former Member · Accepted solution]

Hi Trevor, first of all, I sticked with STA for the thread I created (would switching to MTA help)?

Now, in my understanding, there's a difference in the way Desktop & Web Crystal Viewer controls would work.

For the Desktop, you can create the ReportDocument in new thread, and keep it in that thread forever. However, for web, after I create the object in background thread, the output has to be relayed to the client using an ASP.NET thread itself.

There's nothing like a secondary webform in an ASP.NET app, there's always a single webform processing (and that makes sense if you consider the server-client scenario ASP.NET works in).

I currently cannot imagine how your 2 scenarios can work in my situation. Remember, I am not exporting a report to something like PDf etc but sending Report html to the client for viewing and interaction. I will see further if the 2 scenarios your produced can fit for my purpose somehow. Thanks for replying..

Edited by: r_honey on Sep 21, 2010 1:07 PM

[former_member200290 · Accepted solution]

Honestly, I cannot see how you can properly make use of a thread to process the report in a web application, because the report will have to be handed back to the main thread, which wouldn't work.

Please keep us informed of what you find.

Trevor

[Former Member · Accepted solution]

I have postponed efforts on this one now, but my attempt is to make the Report to export Html in the background thread, that would then be easily handed over to the front-end UI thread for sending to the client.

I am not sure if this is possible at all, because the web-based CR Viewer simply generates an error when its not working on the front-end UI thread.

If anyone from CR here can confirm whether CR ASP.NET Viewer control is capable of performing its processing on a background non-ASP.NET thread pool thread, that would be great saving many a hours of productive time.

I will try this later, but I really hope if this gets some solution with CR reports taking many a seconds of CPU time blocking the limited front0end UI threads available to ASP.NET.