in reply to Spreadsheet::ParseXLSX or Spreadsheet::ParseExcel doesn't work with .xlsx

Are you sure that the cell actually exists? I seem to recall having an issue like this last year, where some cells never had a value and didn't exist. If I recall correctly, merged cells had their neighbors missing, too. I don't have a copy of Excel to double-check it (or the final version of the program, it's on a different machine), but here's a fragment of an earlier version where I was reading from the spreadsheet:

sub get_worksheet_data { my $worksheet = shift; my ($row_min, $row_max) = $worksheet->row_range(); my ($col_min, $col_max) = $worksheet->col_range(); my @data; # Read sheet into array for my $row ($row_min .. $row_max) { for my $col ($col_min .. $col_max) { my $cell = $worksheet->get_cell($row, $col); next unless defined $cell; # Try to detect dates my $v = $cell->value(); my $u = $cell->unformatted(); my $T = $cell->{Type}; my $result = $T;

See that "next unless defined $cell;" statement? If memory serves, I had the same issue you seem to be encountering, where cells don't necessarily exist. In my project, I had a post-processing phase where I copied the value from the previous row into the cell whenever I found a missing cell. (It was a human-readable report, so that was the expected input: blanks meant "same as the row above".)

The "Try to detect dates" section was heinous (omitted) as there were multiple date formats people used (and they weren't always actual dates. That was one of the most annoying parts of the project.

The *most* annoying part of the project is that the XLSX parser is so much slower than the binary file parser. (It took somewhere between two and three *minutes* to parse the spreadsheet. It wasn't a terribly large spreadsheet.)

...roboticus

When your only tool is a hammer, all problems look like your thumb.