Wow, this is doubly cool...  it solves another issue I have been having as well, trying to export large datasets with the WebexcelExporter.

Right now, there is no such statement as WebExcelExporter1.Export(myworksheet).... or WebExcelExporter1.Export(myDataSet)... or WebExcelExporter1.Export(mySqlDataReader)...  (feature requests there, hint hint).

This article shows how to take the Worksheet object directly to the response stream without the WebExcelExporter.

A person could modify this code to accept a simple sqldatareader, minimizing memory requirements for exporting large datasets.  Speaking of large datasets, I bet this is faster than WebExcelExporter too.

Thanks!

In your opinion, should I look for speed improvements in Workbook.Save in the next release?

I need something to tell my clients... If it is unlikely to be improved in the next release, I need to purchase another solution just for the exports.

Hello Rob Hudson,

This is just an update that I am currently working on an isolated sample using a console application type and also running the comparison on my local machine for the library provided in SpreadsheetGear and Infragistics.Documents.Excel.

I will send another update to the thread on my progress on mid-day tomorrow.

Let me know if you have any questions with this matter. Thank you.

I understand.  I don't need to make a decision on this today, just sometime in the next week or so.

Also, one thing I didn't mention, but something your engineers might want to look at... 

When I populate the Worksheet using the Tasks.Parallel.ForEach loop, it will occassionally throw an "object no found" error trying to fill the cell.  That is why it is in a "try-catch" clause.  So after export, there are a handfull of cells that didn't populate.  That's probably something they will want to fix...

Thanks, - Rob

Hello Rob Hudson,

When sending in examples for using try and catch is not be good practice to send without providing code on how the exception is being handled in the catch block. The main reason is because it makes it difficult to debug and knowing whether an exception has been thrown. Most likely it would not be necessary to add try and catch blocks because the targeted application type would simply provide information about the exception details to the user.

As far as the usage of "Tasks.Parallel.ForEach" function my knowledge is limited in this area and also threading. It would be best for our engineers to take a look at the sample provided using a console application type when using the Infragistics.Documents.Excel library because it is not required to use in the ASP.NET platform.

Let me know if you have any questions with this matter. Thank you.

Understood...  Duane, the reason I didn't have handling for the try/catch block is that my intent was to just ignore the error...  I was just trying to get a build time.

I understand (while being surprised) about it not being thread safe.  I will submit a feature request.

Just pinging you guys to see if there has been an update to this issue for the next release.

I am experiencing more pressure from the client to have a solution, and I need to know whether I should wait for Infragistics.