Updating to 3.2 gives me this new error which 3.1 did not exhibit, when loading a certain XLS file: java.lang.RuntimeException: DimensionsRecord was not found at org.apache.poi.hssf.model.Sheet.<init>(Sheet.java:310) at org.apache.poi.hssf.model.Sheet.createSheet(Sheet.java:161) at org.apache.poi.hssf.usermodel.HSSFWorkbook.<init>(HSSFWorkbook.java:282) at org.apache.poi.hssf.usermodel.HSSFWorkbook.<init>(HSSFWorkbook.java:196) at org.apache.poi.hssf.usermodel.HSSFWorkbook.<init>(HSSFWorkbook.java:178) The file unfortunately contains contact information and thus cannot be distributed, but as this appears to be some kind of sanity check, perhaps it can be reduced to a log warning instead of throwing an exception.
According to the documentation, the DimensionsRecord *is* mandatory. POI has more than 200 test files that seem to obey this rule. So it's probably not a good idea to relax that constraint in POI without understanding the problem better. Does re-saving the file in Excel make the problem go away? If not, perhaps you are able to whittle the file down to something that still produces the problem but does not contain any sensitive data. If you can upload a sample file that reproduces the problem this will help a lot. Alternatively, you could try running BiffView and filtering the output (e.g. with grep) for "Offset=0x". That should produce output like the following: Offset=0x00000000(0) recno=1 sid=0x0809 size=0x0010(16) Offset=0x00000014(20) recno=2 sid=0x00E1 size=0x0002(2) Offset=0x0000001A(26) recno=3 sid=0x00C1 size=0x0002(2) Offset=0x00000020(32) recno=4 sid=0x00E2 size=0x0000(0) Offset=0x00000024(36) recno=5 sid=0x005C size=0x0070(112) ...which should be quite safe to upload, but still help a little bit in diagnosing this bug. Perhaps you could also upload similar filtered BiffView results from the file as re-saved by Excel.
i have a spreadsheet with the same problem, which also contains sensitive information. an output from biff grepped with offset=0x is available here: http://www.smallsoft.com/poi/smallsoftbiff0.txt it is 2550 lines, so i did notwant to upload it here, and i dont know how useful it is. i get the bug from linux.
Fixed in svn r721586 Thanks (Nils) for the upload of smallsoftbiff0.txt. From that output I can see that the DIMENSION record is only present on sheets with rows/cells. Excel(2007) reads the such files OK, and automatically re-adds the DIMENSION record. Excel even tolerates missing DIMENSION records on sheets *with* rows/cells. Perhaps the OOO documentation should be updated to reflect this. Do either of you know which application(s) produced these files?
i do not know exactly which application made the file i biffviewed, and my system received files from many different users, which may use different versions of excel, but it was probably created with a microsoft excel version. actually reading the file into openoffice 2.0.3 and saving it again creates a file which poi can read, but unfortunately this is not practical to do with every spreadsheet that fails in our application. we have seen several other files with the same problem. will poi be changed to accept suceh spreadsheets (and maybe reconstruct the missing dimension records) or is there a workaround for this? i did not dare change the staus since i dont know how you people normally do this, but is this bug actually RESOLVED FIXED?
(In reply to comment #4) > i did not dare change the staus since i dont know how you people normally do > this, but is this bug actually RESOLVED FIXED? Yes. You can see the changes in svn trunk (svn r721586). If you prefer, download a nightly build from http://encore.torchbox.com/poi-svn-build/ (probably available tomorrow - 20081130), or wait for the next 3.5-beta5 release.
testing the spreadsheet that failed before still fails with the SAME error message with poi-3.5-beta4-20081130.jar and -1208.jar. it works without this error in for instance with poi-3.0.1-FINAL-20070705.jar. (In reply to comment #5) > (In reply to comment #4) > > i did not dare change the staus since i dont know how you people normally do > > this, but is this bug actually RESOLVED FIXED? > > Yes. You can see the changes in svn trunk (svn r721586). If you prefer, > download a nightly build from http://encore.torchbox.com/poi-svn-build/ > (probably available tomorrow - 20081130), or wait for the next 3.5-beta5 > release. >
Created attachment 23029 [details] Sample file which seems to reproduce the reported error When opened with POI 3.2 this file raises an exception with the following stack trace: Exception in thread "main" java.lang.RuntimeException: DimensionsRecord was not found at org.apache.poi.hssf.model.Sheet.<init>(Sheet.java:310) at org.apache.poi.hssf.model.Sheet.createSheet(Sheet.java:161) at org.apache.poi.hssf.usermodel.HSSFWorkbook.<init>(HSSFWorkbook.java:282) at org.apache.poi.hssf.usermodel.HSSFWorkbook.<init>(HSSFWorkbook.java:196) at org.apache.poi.hssf.usermodel.HSSFWorkbook.<init>(HSSFWorkbook.java:312) at org.apache.poi.hssf.usermodel.HSSFWorkbook.<init>(HSSFWorkbook.java:293)
The supplied attachment (id=23029) seems to produce the original exception exactly, and opens OK with latest svn trunk. I just checked the same nightly build from http://encore.torchbox.com/poi-svn-build/poi-source-3.5-beta4-20081208.zip and it appears that the change (svn r721586 ) is not present there (For reference - the previous version has an error message "DimensionsRecord was not found" and the latest version has a warning message "DIMENSION record not found even though row/cells present"). I'm not sure what is going wrong on torchbox. Until that is fixed, you can build directly from an svn checkout or wait for the next beta release.