[Octave-bug-tracker] [bug #59277] xls2oct and/or openxls behave unexpected

[Dennis]

Follow-up Comment #11, bug #59277 (project octave):

> Can you pleas try again with a patched xlsopen.m from here:

I tested it. First reinstated my java library and checked the functioning of
the old xlsopen with my test script (previous comments). Indeed it did use UNO
the first run, as previously. Next, I copied the new xlsopen, unloaded io and
loaded io, and reran the test script. This time it uses OCT, as specified. 

I next changed the script to specify using UNO, and that works as well: it now
uses UNO. Since these are the only two interfaces I have available on my
machine, I can't test xlsopen for the other interfaces, but based on my
limited testing it seems to work as it should now.

Comming back to your question in comment #9:
> In your workflow, can you write spreadsheet contents to .csv files before
processing?

I am afraid not. I am using Excel sheet to store some data, and created an
Octave script that is actually being used as a API in a webservice. The excel
file uses some simple formualas and formatting to properly check the validity
of the data in it. I surely know that a dbase would be better, but that takes
quite a bit implementation. Moreover, the Excel doesn't actually contain that
much data. It is mostly strings and some numbers. The problem is that the
commands used for the API cannot depend on previously loaded data, so every
API call the excel is opened and loaded again. Consequently, there are quite a
few loads, and the cell2mat used for SharedString really takes it's toll in
performance. I will try and see if cellfun works better.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?59277>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/