I downloaded the trial version of the winforms suite. 8.3 to test out the Excel export. The application is using the following references:
Infragistics3.Excel.v8.3 version# 8.3.20083.1009Infragistics3.win.ultrawingrid.excelexport.v8.3 version#8.3.20083.1009
The development machine is up to .net framework 3.5. I cannot get the export to excel to put out more than 65k records without throwing an exception. Any assistance would be very helpful. Thank you.
What file format are you exporting to? This sounds like you're hitting the limitation on the number of rows that an Excel 97-to-2003 file can hold. If you're not specifying a format in your call to Export(), then you're exporting to Excel 97-to-2003 format automatically.
To export into Excel 2007 format (and to take advantage of its larger row count limit), use one of the overloads of the Export() method that takes a WorkbookFormat enumeration for a parameter, and pass WorkbookFormat.Excel2007 for that parameter.
Vince, thank you for the quick reply.
I changed the output format to use WorkbookFormat.Excel2007 and am still hitting the limit. We are using Visual Studio 2005. Not sure it that matters. Office 2007 is installed on the machine, as is .net 3.5 framework.
If there is anything else I can do, please let me know. Thanks again.
I answered your question in your other post.
http://community.infragistics.com/forums/p/33116/232324.aspx#232324
HI,
I am trying to export more than 66K rows to excel. But with out the exception, i have to split the rows(after 65535 )to next worksheet when i have framework that developed in VS 2005(.Net 2.0) , Excel 2007 and Infragistics2.Excel.v9.2. Is this possible? If yes how to do this.
If you're using Visual Studio 2005, that may make a big difference.
The assemblies you need are compiled against version 3.0 of the .NET Framework. You need to create an application that's compiled against either version 3.0 or 3.5 of the .NET Framework, which you'll need Visual Studio 2008 to do.
Since you're using Visual Studio 2005, and thus are compiling against version 2.0 of the .NET Framework, our assemblies are probably ignoring the WorkbookFormat setting altogether.