You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
OpenXML worksheets that have been created without the row index attribute populated on the row elements and without the reference attributes populated on cells fail to load correctly.
Where these attributes (that are optional in the specification) are not populated, the code that loads the spreadsheet fails to set the correct row number on all but the first row. As a result, exceptions are thrown during the load routine and prevent the data from being accessed. There are several third party components that generate files in this way (including SpreadsheetGear).
The issue appears to be due to the lastRow variable being initialised to zero when every single row is read. This means that the index reverts back to zero when the second row in a sheet is loaded and as a result multiple cells are loaded with the same address. This then creates problems when handling the data type of the cell.
The solution appears to be to move the initialisation of the lastRow variable outside of the main loading loop within the Worksheet.
What is the expected behavior or new feature?
The file should load. Where the reference is missing, ClosedXML should use the row number immediately following that of the last row processed.
Did this work in previous versions of our tool? Which versions?
No
Reproducibility
This is an important section. Read it carefully. Failure to do so will cause a 'RTFM' comment.
The attached workbook can be loaded to illustrate the problem:
Without a code sample, it is unlikely that your issue will get attention. Don't be lazy. Do the effort and assist the developers to reproduce your problem. Code samples should be minimal complete and verifiable. Sample spreadsheets should be attached whenever applicable. Remove sensitive information.
Read and complete the full issue template
Do you want to request a feature or report a bug?
If you are logging a possible bug or feature request, please test with the latest development build first.
Version of ClosedXML
0.95.0-beta2
What is the current behavior?
OpenXML worksheets that have been created without the row index attribute populated on the row elements and without the reference attributes populated on cells fail to load correctly.
Where these attributes (that are optional in the specification) are not populated, the code that loads the spreadsheet fails to set the correct row number on all but the first row. As a result, exceptions are thrown during the load routine and prevent the data from being accessed. There are several third party components that generate files in this way (including SpreadsheetGear).
The issue appears to be due to the lastRow variable being initialised to zero when every single row is read. This means that the index reverts back to zero when the second row in a sheet is loaded and as a result multiple cells are loaded with the same address. This then creates problems when handling the data type of the cell.
The solution appears to be to move the initialisation of the lastRow variable outside of the main loading loop within the Worksheet.
What is the expected behavior or new feature?
The file should load. Where the reference is missing, ClosedXML should use the row number immediately following that of the last row processed.
Did this work in previous versions of our tool? Which versions?
No
Reproducibility
This is an important section. Read it carefully. Failure to do so will cause a 'RTFM' comment.
The attached workbook can be loaded to illustrate the problem:
Without a code sample, it is unlikely that your issue will get attention. Don't be lazy. Do the effort and assist the developers to reproduce your problem. Code samples should be minimal complete and verifiable. Sample spreadsheets should be attached whenever applicable. Remove sensitive information.
Code to reproduce problem:
NoReferencesOnRowsOrCells.xlsx
The text was updated successfully, but these errors were encountered: