XLSREAD() Bug(?) -- Fails to return empty columns in xlRegion

Just discovered a nasty apparent bug in xlsread -- column of data is something like

M012345  NAME FUND empty empty VAL1 VAL2 ... empty empty VAL1 VAL2

'empty' above stands for a cell which hasn't values at present but represents a previous year that might at some time be included in an analysis but for which, at present, the effort to go back and retrieve same hasn't been undertaken. There are two sets of values over the same sets of years illustrated above.

The statement

[V,ID]=xlsread('filename.xls','SheetName','A3:AF46');

turns out to return

size(ID) ==> 44,2  % OK
size(V)  ==> 44,27 % WRONG!!!!!

It appears that xlsread smushes together the empty columns into a single one and therefore, the selection of the area and the association with the years implied by the location in the sheet by column is lost.

This occurs as written in an m-function and also if one uses the "-1" option and interactively selects the area.

Anybody else confirm this behavior and it seems to me it's a definite bug as it surely isn't documented and it screwed an analysis up royally that I didn't discover from months ago until just now when returned to the scene to make some modifications.

[Dasharath Gulvady]

I can't seem to reproduce the issue you mentioned. Can you create a sample Excel file and share? I tried with the following two rows in the Excel(columns D and E are empty):

M12345 abc 100 123 456 M12345 def 200 123 789

>> [V, ID]=xlsread('Sample.xlsx', 'Sheet1')

size(V) ==> 2,5 %OK

[Image Analyst]

You forgot to attach the workbook so people can try it for themselves. If you're going to make such a bold claim as a bug then you should back it up with something that conclusively demonstrates it.

[dpb]

Well, I hadn't firmly concluded it was/is a bug rather was reporting the observed behavior and asking for opinion/confirmation (or lack thereof depending upon various versions, OS, etc., etc., etc., ...).

I hadn't wanted to put the whole file out as it has people-sensitive data in it; figured the description was simple enough to build a test file. But, that is inconvenient for the respondent, granted.

But, I'll sanitize and shorten and put up a sample...

Well, this is peculiar! I had inserted dummy data in the original for at least one entry in each column to make the problem go away; in trying to recreate it now (apparently) having once had data in those columns simply clearing the values in those cells didn't cause the issue to reappear. No klew on that symptom, either.

I'll see if I can recreate the issue but don't have time for further exploration at the moment.

Even more bizarre; but then again, it does have Excel in the mix; not the first time I've seen something peculiar there (and undoubtedly won't be the last, either!)

ADDENDUM

The original sheet was built by a link and formulas to a whole bunch of other notebooks, one for each year; the point of this one was to consolidate over years for time analyses that the bookkeepers don't do. It looks like to have any chance't of recreating the issue I'll have to do the overall process over from scratch altho now I'm not very confident it'll come back when do as it seems to likely have been a fignewton of an issue internal to the particular spreadsheet somehow having done something didn't recognize that caused the symptom.

Hence, it likely is not an actual issue with xlsread but one internal to Excel; xlsread simply reported what it found which was invisible to the user interface but some sort of issue in those columns.

I had tried everything I could think of, however, to get it to work correctly other than the dummy data that I finally resorted to and was consistently getting only 27 columns instead of 32 returned for the numeric subsection. What convinced me it was funky was that the user import did the same thing before the sheet modifications.

Oh well, as said, "it's Excel"... :(