A while back, Duane wrote an article in this forum detailing how to do an ajax postback that resulted in the Excel document downloading. It was quite good and pretty deep, but I never got a chance to implement it.
Now I am back to try it, and I can't find the article. It looks like somebody cleaned out the forums, deleting some good content in the process.
Can somebody please retrieve it?
And can somebody please give your developers someplace they can post this kind of stuff without worrying about a moderator deleting it?
While the article doesn't appear to be publicly visible (can't find it through search or by browsing the forum), it is available by direct link.
Here is the link, if it's helpful to anyone else.
http://forums.infragistics.com/forums/t/55904.aspx
Thanks Duane! Keep it coming!
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.
Hello Rob Hudson,
Thanks for the attached sample on the thread.
I ran the sample and clicked on the Test save option and "Run Test" button using the WebExcelExporter method. For 50,000 records with 12 columns on my local machine took about 1 min, 18 secs, 84 ms that is much faster than 4 min, 57 sec, 673 ms. Clearly what's being reported and the sample attached that I ran I believe looks to be a difference to the environment.
Also when using the WebExcelExporter control is a feature for the WebDataGrid that is used for the WebDataGrid control directly. As far as doing a comparison on SpreadsheetGear, is there a feature in using SpreadsheetGear that provides a web interface in the ASP.NET platform that would render a grid and export to excel? Most likely this would be a more direct comparison.
When using the WebExcelExporter control there is definitely a lot of features and functionality provided to be productive on. In the samples browser demonstrates the key usage here: http://samples.infragistics.com/aspnet/Samples/WebDataGrid/Data/Excel-Exporter/Default.aspx?cn=excel-exporter&sid=325f8ea4-0a5f-4a1a-87fd-1d39d4f746d2. There is a rich feature list and also supporting many of the formats such as Excel 97, 2003, and 2007 that may involve a tradeoff to performance which is expected.
Let me know if you have any questions with this matter. Thank you.
Duane,
Thanks for the feedback..
I know that WebExcelExporter isn't ever going to match SpreadsheetGear. It has a lot more work to do as far as applying CSS, etc, and is tied closely to the WebDataGrid control. That's ok.
What I am looking for is an acceptable solution that bypasses the WebExcelExporter and uses Infragistics.Documents.Excel. If we were to do a feature comparison, it would be between Infragistics.Documents.Excel and SpreadsheetGear.
I am trying to get Infragistics.Documents.Excel to work for these exports. SpreadsheetGear is another $1k per license, and I have already purchased a library that is supposed to handle Excel exporting.
Were you able to duplicate the resource issues that I noted with Workbook.Save?
Thanks for the update.
I will submit this as a log for our engineers to take a look at. First I would like to demonstrate this as a console application. The main reason is because demonstrating the performance would not be involved in a particular platform.
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.
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.
The fix for development issue 89817 is now in the latest service release. You can download within My Keys & Downloads page.
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.
Thanks for the update on the thread.
For the performance improvements on using the Excel library I have logged bug id 89817 on this using the sample code that was provided in this thread to have our engineers look into this. Also private case CAS-72672-JNFCD2 has been created and you can find this case number in the support activity page here: https://es.infragistics.com/Membership/MySupport.aspx.
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.
The objects in the Excel library are not thread safe, so you should not be using Parallel.ForEach to populate a Worksheet with data. You can submit a feature request to make these objects thread safe. Until that is implemented, you should be populating the objects synchronously.