Hi,
we need some help with the excel export function of the infragistics ultragrid version 11.2.
Situation:
Our application handles a high amount of data (currently, over 35,000 rows. each row with 20 sub rows) and provides a functionality to export filtered (and non-filtered) data to an excelsheet.
Problem:
The infragistics excel export function needs round-a-bout an hour to export the 700,000 rows (35,000 * 20) to an excelsheet. Even if we try to export only a small amount of rows (place a row filter)!
Technical details:
For each row we intercept the InitializeRow event and set some object properties:
If e.Row.IsFilteredOut Then e.SkipRow = True e.SkipDescendants = True e.Row.Band.ColHeadersVisible = False e.Row.Band.HeaderVisible = False End If
If e.Row.IsFilteredOut Then
e.SkipRow = True
e.SkipDescendants = True
e.Row.Band.ColHeadersVisible = False
e.Row.Band.HeaderVisible = False
End If
We tried to export the rows with and without handling the InitializeRow event, but the result is the same.
Sample:
We add a sample application to this post, which generates a xml file with 10000 main and 20 sub rows. This example shows the simplified way of our export procedure. All other parts of our export functionality have been checked for performance issues and we come to the conclusion that only the excel export function of the ultragrid can be the bottle neck of our application.
Our question is:
Is there an easier/faster way to export filtered grids with the excel exporter? Or we doing something basicly wrong?
Sincerely,
Kai
The issue has been resolved. I suggest that you upgrade your application to the latest version of NetAdvantage and download and install the latest Service Release. Let me know if that resolves your issues.
Thomas,
This issue has been submitted to development for further review. The reference number for this development item is TFS115020. A support case has also been opened for you and the reference number for the support case is CAS-93962-576WBW.
I will leave this case open and update you with any new information after the review. You can also continue to send updates to this case at any time.
You can view the status of the development issue connected to this case by logging into your account on our website, hovering to the "My Support Activity" dropdown and selecting the "Development Issues" tab.
Hi Kai,
Sorry, it's a long thread, and I forgot about your mention of filtering in your initial post. I tried your sample again, and I still get the same results in 10.2 - but this is probably because I am using a service release that you are not.
I went back and tried it again in 9.2 and it does work as you say - it exports the grid in under 4 seconds.
I have forwarded this thread over to Infragistics Developer Support and asked them to create a case for you and write this issue up for further investigation. My guess is that whatever changed here was changed due to a necessary bug fix, but we will see what we can do.
Hi Mike,
I think my previous description was not clear enough. We don't want to export the whole grid. We only want to export a bunch of filtered rows. In our second example (WindowsApplication1, v10.2) the export of filtered rows works really fast (12 rows in 1,xx seconds), but in our first example (ExcelExportTestApplication, v11.2) it tooks hours to export the 12 filtered rows. The export process is the same, only the .net framework and infragistics versions are different.
To reproduce the different processing times between the two versions do the following steps:
1. Open the application2. Filter "Node1_ID" Column with the value "100" (12 rows remain)3. Click the export button
An overfilling of the excelsheet is not possible, because our application already got a method to raise an error when the excel limits are reached. But the whole functionality is worthless until the export under infragistics 11.2 is that slow.
Select Case .FilterIndex
Case 1 'xlsx Select Case Me.IsExportableToExcel(Grid, ExcelVersion.Excel2007, Me.ExportWithHierarchicalIndentation) Case GridExportableToExcel.MaxBandDepthOverflow 'Throw Error Message Return False Case GridExportableToExcel.MaxColumnCountOverflow 'Throw Error Message Return False Case GridExportableToExcel.MaxRowCountOverflow 'Throw Error Message Return False Case GridExportableToExcel.UnspecifiedCheckError 'Throw Error Message Return False Case GridExportableToExcel.Yes If .FileName.EndsWith(".xlsx") = False Then .FileName = .FileName & ".xlsx" End If End Select Case 2 'xls Select Case Me.IsExportableToExcel(Grid, ExcelVersion.Excel2003, Me.ExportWithHierarchicalIndentation) Case GridExportableToExcel.MaxBandDepthOverflow 'Throw Error Message Return False Case GridExportableToExcel.MaxColumnCountOverflow 'Throw Error Message Return False Case GridExportableToExcel.MaxRowCountOverflow 'Throw Error Message Return False Case GridExportableToExcel.UnspecifiedCheckError 'Throw Error Message Return False Case GridExportableToExcel.Yes If .FileName.EndsWith(".xls") = False Then .FileName = .FileName & ".xls" End If End Select End Select
Case 1 'xlsx Select Case Me.IsExportableToExcel(Grid, ExcelVersion.Excel2007, Me.ExportWithHierarchicalIndentation)
Case GridExportableToExcel.MaxBandDepthOverflow
'Throw Error Message
Return False
Case GridExportableToExcel.MaxColumnCountOverflow
Case GridExportableToExcel.MaxRowCountOverflow
Case GridExportableToExcel.UnspecifiedCheckError
Case GridExportableToExcel.Yes
If .FileName.EndsWith(".xlsx") = False Then
.FileName = .FileName & ".xlsx"
End Select
Case 2 'xls
Select Case Me.IsExportableToExcel(Grid, ExcelVersion.Excel2003, Me.ExportWithHierarchicalIndentation)
If .FileName.EndsWith(".xls") = False Then
.FileName = .FileName & ".xls"
Sincerely,Kai
I tested the new sample you posted, which uses v10.2 of the Infragistics assemblies and I am not getting any different results with these assemblies. It's still taking far longer than a minute to export (or even to blow up, which is what it should be doing since it's still using xls and xlsx format).
I'm using the latest service release, of course, so just to be thorough, in case you are using an older version without the service releases that I have, I tried going back all the way to v8.1 and I still get the same results.
So if you are getting different results, I don't think it's the version of the Infragistics Assemblies that is causing it.
Like I said... it's not the export process that is taking the time. If it were, then the application would be blowing up as soon as it hit 65,000 rows, which is the limit in Excel.
If this application worked at all, without raising an exception, then it must have been exporting far less than the 2 million plus rows you are exporting here. It could not possibly have worked in any version, because Excel simply doesn't support that many rows in a single worksheet.