ERROR: The list of column names should have the same size as the list of column types.

[JamoCA]

trafficstars

I have a question regarding this error.

The list of column names should have the same size as the list of column types.

An XLS file was uploaded that had 23 column names. The data was populated, but only columns 1-19 contained content while columns 20-23 were intentionally empty. This use case doesn't happen that often, but it does happen. (Would this error have been thrown if the last column was populated and the proceeding 4 columns were empty?)

Is this an actual error? Is there any way to ignore it and import the data while treating the extra trailing, empty cells as "blank"?

NOTE: I understand the issue if it was reversed and there were 19 headers with 23 columns of data. I'm not sure if this should result in an error or if only the named columns should be imported (or if names should be auto-generated for empty columns.) We used a CFX tag about 10-15 years ago that (I believe) autogenerated COL_X headers for unnamed columns that it detected.

Thanks.

[JamoCA]

I upgraded to latest version and the error message (on a different XLS file) is:

The list of column names should have the same size as the list of column types.
Size of column names 19 is different from size of column types 18;

The last column in the Excel file is intentionally empty.

[cfsimplicity]

Hi James. That error doesn't come directly from the library but from the use of QueryNew() somewhere. I can't seem to replicate the conditions though. I've tried with a simple XLS created on the fly, but it works as expected in both Lucee and ACF2016:

path = "c:\temp\test.xls";
headerRow = [ "column one", "column two" ];
dataRow = [ "row 1 col 1 value" ];
spreadsheet.newChainable( "xls" )
 .addRow( headerRow )
 .addRow( dataRow )
 .write( path, true );
result = spreadsheet.read( src=path, headerRow=1, format="query" );
WriteDump( result );

Can you provide a test case that demonstrates the issue?

[cfsimplicity]

Meantime, I looked into the "reverse" case you mentioned and found problems exactly as you describe. See #265