Thank you for your reply, Mark. We are not actually creating the files, but are receiving the files from our clients, and we must read and parse them to get to the data they are sending to us, so producing incompatible files will never be a problem. I do have the source for POI 3.6, but I just wanted to know if anyone knew of a technical reason why the limit was hard-coded -- like if some counter was a short value that might overflow, for instance -- before proceeding.
Perhaps it would be a good idea to allow the API users to select the file format version, with perhaps some call like setVersion(org.apache.poi.ss.SpreadsheetVersion), rather than fork the code. ---Mark > -----Original Message----- > From: MSB [mailto:[email protected]] > Sent: 24 April, 2010 3:17 AM > To: [email protected] > Subject: Re: Max number of rows in an HSSFSheet? Max row num for > HSSFRow? Excel 97? > > > Hello Mark, > > The reason is that the limit applied both to the number of rows in the > sheet > and cells in the column was imposed by Microsoft when the file format > was > originally devised. With the introduction of Excel 2007 - I think it > was > that version at least - the then new SpreadsheetML or OOXML file format > offered the ability to create much larger sheets. The earlier file > format - > the binary one - was retrofitted to comply but POI cannot do similar. > The > reason is that POI must create files - that is the binary format .xls > files > - that can be read by earlier versions of Excel and they would not be > able > to handle sheets with more than 65536 rows. > > As to your subsequent question concerning removing the limit on your > own > version of POI, then I do not know the answer but would say why not try > it > and see what happens. You can download the source for the project, make > the > necessary changes, compile the code, build the archives and run tests. > Be > aware however that if a binary file that is produced in this way, has > more > than 65536 rows and is ever to be read on - say - Excel 2003, then it > is > likely that it will fail. > > Yours > > Mark B > > > mark.barnes wrote: > > > > Hi - > > > > I recently tried to read a huge Excel file using POI 3.6 and received > > this Exception: > > IllegalArgumentException: Invalid row number (65536) outside > > allowable range (0..65535). > > > > I looked at the source and found the code for method > > org.apache.poi.hssf.usermodel.HSSFRow.setRowNum() where the exception > is > > thrown: > > > > > > /** > > * set the row number of this row. > > * @param rowIndex the row number (0-based) > > * @throws IndexOutOfBoundsException if the row number is not > within > > the range 0-65535. > > */ > > public void setRowNum(int rowIndex) { > > int maxrow = SpreadsheetVersion.EXCEL97.getLastRowIndex(); > > if ((rowIndex < 0) || (rowIndex > maxrow)) { > > throw new IllegalArgumentException("Invalid row number (" + > > rowIndex > > + ") outside allowable range (0.." + maxrow + ")"); > > } > > rowNum = rowIndex; > > if (row != null) { > > row.setRowNumber(rowIndex); // used only for KEY > > comparison (HSSFRow) > > } > > } > > > > > > > > My question is, is there a reason that the row limit is hard-coded to > be > > the limit for Excel 97 from > > org.apache.poi.ss.SpreadsheetVersion.EXCEL97? Is there something > else > > on the code that would fail if the limit from > > org.apache.poi.ss.SpreadsheetVersion.EXCEL2007 were used? > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > > > -- > View this message in context: http://old.nabble.com/Max-number-of-rows- > in-an-HSSFSheet---Max-row-num-for-HSSFRow---Excel-97-- > tp28345332p28348788.html > Sent from the POI - User mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
