bugGNU Octave - Bugs: bug #49510, after an xlswrite the spreadsheet...

 
 

bug #49510: after an xlswrite the spreadsheet is corrupted

Submitter:  Steven Weinberg <wstevena>
Submitted:  Tue 01 Nov 2016 08:47:05 PM UTC
   
 
Category:  Octave Package Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  philipnienhuis
Originator Name:  Steve Weinberg Open/Closed:  * Closed
Release:  * 4.2.0-rc3 Operating System:  * Microsoft Windows
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 09 Nov 2016 09:18:56 PM UTC, comment #32: 

Thank you for the explanation. So I will stick to the 32-bit Octave, which can find my Java.

I don't know if my 64-bit Java is non-standard or not. From comment #22 it appears to be typical, but maybe something is atypical in my search path, registry or environment variables.

Steven Weinberg <wstevena>
Wed 09 Nov 2016 06:53:53 PM UTC, comment #31: 

I see what you mean.

Some background:
What happen when you call xlsread or friends, is that it in turn calls xlsopen (which will "open" the spreadsheet file") that in turn calls routines that find out what "external" spreadsheet I/O interfaces are available; "external" meaning depending on SW outside Octave.
The order in which interfaces are searched is roughly COM, <Java based interfaces>.
If no working external interface is found, Octave falls back to OCT (= native Octave code).

The error you see means that although only COM was requested, and hitherto the Java based interfaces themselves are disabled, Octave nevertheless searches for Java. That shouldn't be needed, admittedly, but normally doesn't harm.
However, apparently your Java setup is unsatisfying so you see errors from Octave routines (not io package routines) invoked by the io package.

I expect similar errors to happen when you try xmlread.m (also in the io package).

A workaround will be in a next io release - io-2.4.5 has just been released.
But again, AFAIU the issue lies with your Java setup.

I'll close this bug report.

Philip Nienhuis <philipnienhuis>
Group Member
Tue 08 Nov 2016 07:04:11 PM UTC, comment #30: 

I appreciate all the insight you can provide on this.  My previous comment about Java was based on this situation:

When I use the 64-bit Octave I get the following error (which I do not get with the 32-bit Octave).  I specifically set the 'COM' interface. Here is the offending line:

pauseflag = xlsread(intfname,'MAIN','pauseflag','COM'); 

Output:
Checking requested interface(s):
error: javaMethod: library open failed: C:\Program Files (x86)\Java\jre7\bin\client\jvm.dll
error: called from
    javaclasspath at line 64 column 16
    getxlsinterfaces at line 70 column 11
    xlsopen at line 161 column 21
    xlsread at line 197 column 11
    gvar2 at line 93 column 11

Steven Weinberg <wstevena>
Tue 08 Nov 2016 06:34:45 PM UTC, comment #29: 

Yeah, SSD HDDs have issues with low level drivers or -firmware. A nasty issue that affects both Windows and Linux.

To set the record straight as to COM & Java: those two are completely unrelated.

The COM interface (which invokes Excel behind the scenes and does NOT require Java) works equally well with 32- and 64-bit Octave; the only important thing is that it doesn't work with 64-bit MS-Office.

The other interfaces except OCT all require Java but not the OF windows package; of those interfaces, Apache POI offers .xlsx (Excel 2007+) support.

Philip Nienhuis <philipnienhuis>
Group Member
Tue 08 Nov 2016 01:46:40 PM UTC, comment #28: 

Yes it is an SSD hard disk. Would I have better luck if I put the spreadsheet on a slower network drive?

BTW, the reason I am able to use COM rather than OCT was by switching to the 32-bit version of Octave. The 32-bit version was able to find the corresponding version of Java, without which COM objected.

Steven Weinberg <wstevena>
Mon 07 Nov 2016 09:55:26 PM UTC, comment #27: 

As to 2: yes that's what I thought.  Do I guess right that D: is on an SSD hard disk or a very fast spinning hard disk?

I think similar issues were raised in e.g., https://savannah.gnu.org/bugs/?47712

That it even happens with COM is intriguing - I figured it only happened with OCT interface.
I'm afraid there's little to be done it about except adding in a delay.

AFAIK all bugs reported have been solved, so I'll probably make an io-2.4.5 release soon.

Unless anything urgent comes up I'll close this bug report as soon as io-2.4.5. is out.

Philip Nienhuis <philipnienhuis>
Group Member
Mon 07 Nov 2016 06:41:00 PM UTC, comment #26: 

1. I am reading and writing from the D: drive, which is for data.

2.  When I set the delay to 0.25 I still had the "not writable" error, but at a delay of 0.5 the write was successful. 



Steven Weinberg <wstevena>
Mon 07 Nov 2016 05:58:11 PM UTC, comment #25: 

Some questions in return, to help diagnose your setup:

  1. Does your PC have an SSD drive from/to which you read/write the spreadsheet files?


  1. What happens if you put in a little delay? Along the lines of:


intfname='book1.xlsx';
[status,sheets] = xlsfinfo(intfname);
wnames=sheets(:,1);
pause (0.25);             %% <= A little delay
xlswrite(intfname,wnames,'MAIN',"A55:A100");


If it doesn't help, put in a little more delay, but no more than 0.5 second.

Philip Nienhuis <philipnienhuis>
Group Member
Mon 07 Nov 2016 02:21:51 PM UTC, comment #24: 

I am still finding some unusual behavior.  When I run the script test.m:

intfname='book1.xlsx';
[status,sheets] = xlsfinfo(intfname);
wnames=sheets(:,1);
xlswrite(intfname,wnames,'MAIN',"A55:A100");


I get:

>> test

Detected XLS interfaces: COM*; (* = default interface)
error: xlsopen.m: write mode requested but file book1.xlsx is not writable

but if I run each line individually via "run selection" I get:

>> xlswrite(intfname,wnames,'MAIN',"A55:A100")


ans =  1


This result is persistent and repeatable on my setup. Is there a diagnostic function I can try to determine the reason for the difference between scripted and interactive outcomes?

Steven Weinberg <wstevena>
Fri 04 Nov 2016 09:17:54 PM UTC, comment #23: 

@Mike: correct.

As to "client" and "server" subdirs, if it doesn't work I usually copy the "client" subdir and rename it to "server". On Linux it's a mere symlink.

@Steven: any chance your IT dept, allows .tar.gz files sent through email?

Philip Nienhuis <philipnienhuis>
Group Member
Fri 04 Nov 2016 08:13:11 PM UTC, comment #22: 

I have very little knowledge of Windows or Java, but

Isn't "Program Files" for 64-bit programs and "Program Files (x86)" for 32-bit programs?

It is also the case on Debian, and probably other GNU distributions, that the jvm shared library (libjvm.so instead of jvm.dll) sits in a subdirectory called "client" on 32-bit distributions, but in a directory called "server" on 64-bit distributions.

Does Octave account for the client vs server naming convention on Windows? It does on Debian.

Is the version of Octave being tested here a 32-bit or 64-bit build? Do Octave and JRE have to agree (I would assume yes)? If Octave is a 32-bit build, then that may be why it's only looking for a subdirectory called "client".

Mike Miller <mtmiller>
Group Member
Fri 04 Nov 2016 08:04:52 PM UTC, comment #21: 

Thank you for your efforts. I do have a 64-bit JRE, but something is non-standard about it.  It is found in

C:\Program Files\Java\jre7\bin\server\jvm.dll.

Weirdly, there is no ~bin\client subdirectory, where jvm.dll would be expected to be found. I don't know if this was an error by the company's IT department or intentional. Looking at older versions of Java on my computer, it appears it is intentional.

I would very much like to try out io-2.4.5, but naturally Dropbox is also blocked by the firewall. E-mail and memory sticks are also blocked, so there is no easy work around until it becomes part of a new Octave release, as Octave forge itself is also firewalled.
   
Yes, test.m was my program that contained the script.

Steven Weinberg <wstevena>
Fri 04 Nov 2016 07:03:41 PM UTC, comment #20: 

@ comment #18:
Apparently you have 64-bit Octave, or an Octave built with a 64-bit Java JDK, so then you need a 64-bit JRE.
The good news is that -at least on Windows- 32-bit and 64-bit JREs can coexist perfectly. Simply install a 64-bit JRE.

Then:
I think I've fixed the XML related bugs, some were quite concealed.
If you want you can help me by trying io-2.4.5 here:
https://www.dropbox.com/s/3ykegqe4l79sl6j/io-2.4.5.tar.gz?dl=0

I tried your script, I got this:

>> intfname='book1.xlsx'
intfname = book1.xlsx
>> [status,sheets] = xlsfinfo(intfname)
Detected XLS interfaces: COM*; POI (& OOXML); JXL; OXS; UNO; (* = default interface)

status = Microsoft Excel Spreadsheet
sheets =
{
  [1,1] = Sheet1
  [2,1] = Sheet2
  [3,1] = Sheet3
  [1,2] = Empty
  [2,2] = Empty
  [3,2] = Empty
}
>> wnames=sheets(:,1)
wnames =
{
  [1,1] = Sheet1
  [2,1] = Sheet2
  [3,1] = Sheet3
}
>> xlswrite(intfname,wnames,'MAIN',"A55:A100")
ans =  1


The messages from your script are expected nd the output is fine; except for the line "test at line 7 column 16" that I cannot track down- it must be a program/script from you I suppose.

Philip Nienhuis <philipnienhuis>
Group Member
Fri 04 Nov 2016 02:35:07 PM UTC, comment #19: 

Further testing. I created a blank spreadsheet book1.xlsx using Excel. 

Here is the program:


intfname='book1.xlsx';
[status,sheets] = xlsfinfo(intfname);
wnames=sheets(:,1);
xlswrite(intfname,wnames,'MAIN',"A55:A100");

                                                                 Here is the output:
             
Detected XLS interfaces: COM*; warning:  No Java support found (no Java JRE? no
 Java pkg installed AND loaded?)
warning: called from
    getxlsinterfaces at line 121 column 11
    xlsopen at line 262 column 17
    xlsfinfo at line 91 column 7
    test at line 7 column 16
error: xlsopen.m: write mode requested but file book1.xlsx is not writable

sheets =
{
  [1,1] = Sheet1
  [2,1] = Sheet2
  [3,1] = Sheet3
  [1,2] = Empty
  [2,2] = Empty
  [3,2] = Empty
}

Steven Weinberg <wstevena>
Fri 04 Nov 2016 12:45:59 PM UTC, comment #18: 

The rest of my comment was cut off:

javaaddpath('~\poi-bin-3.15-20160924\poi-3.15/poi-
3.15.jar")

<loads\poi-bin-3.15-20160924\poi-3.15/poi-3.15.jar')
error: javaMethod: could not find library or dependencies: C:\Program Files\Jav
a\jre7\bin\client\jvm.dll
error: called from
    javaaddpath at line 52 column 13

I do have this file, but it is in C:\Program Files (x86)\Java\jre7\bin\client\jvm.dll

Is there a way to tell Octave to look in \Program Files (x86)\ for all Java related files?

Steven Weinberg <wstevena>
Fri 04 Nov 2016 12:39:31 PM UTC, comment #17: 

This is what I get now when I run the program:

Detected XLS interfaces: COM*; warning:  No Java support found (no Java JRE? no
 Java pkg installed AND loaded?)
warning: called from
    getxlsinterfaces at line 121 column 11
    xlsopen at line 262 column 17
    xlsfinfo at line 91 column 7
    test at line 7 column 16

warning: xlswrite - array truncated to 1 by 1 to fit in range A55
warning: called from
    xlswrite at line 184 column 5
    test at line 11 column 1
error: xlsopen.m: write mode requested but file test.xlsx is not writable


I actually do have JRE, but Octave didn't find it:


javaaddpath('~\poi-bin-3.15-20160924\poi-3.15/poi-
3.15.jar")

<loads\poi-bin-3.15-20160924\poi-3.15/poi-3.15.jar')
error: javaMethod: could not find library or dependencies: C:\Program Files\Jav
a\jre7\bin\client\jvm.dll
error: called from
    javaaddpath at line 52 column 13
--verbatim

However jvm.dll resides in 'C:\Program Files (x86)\Java\jre7\bin\client\jvm.dll'

Is there a way to tell Octave where to look for JRE?

Steven Weinberg <wstevena>
Thu 03 Nov 2016 10:23:01 PM UTC, comment #16: 

As to comment #14
Yep, I forgot you also need a Java JRE installed. Bummer :-(

As to the file corruption, I think I found & fixed two bugs. I need a bit more testing here before I can push the affected files.

W.r.t. the issues in comment #15:

- I'll look into the transpose thing. It used to be matlab compatible save for the fact that Octave also returns the used data rectangles for each sheet;

- "not writable" - ??? I cannot confirm that. As I wrote in comment #1 the COM interface worked fine for me.

and finally:

- some investigation is needed for the range parameter in xlswrite. Maybe Matlab silently extends the range to the rectangle required for the data to be written? Or does it do that only if just the top left cell is indicated (i.e., just one cell rather than "cell_addr:cell_addr") ?

Philip Nienhuis <philipnienhuis>
Group Member
Thu 03 Nov 2016 08:57:36 PM UTC, comment #15: 

By the way I just tested the 'COM' interface. I modified the original test file to reflect the difference in the sheets command between Octave and Matlab.  (See comment #8).


intfname='test.xlsx';
[status,sheets] = xlsfinfo(intfname);
poswmat=find(strncmp(sheets, 'wmat', 4));
wnames=sheets(poswmat);  %remove transpose
xlswrite(intfname,wnames,'MAIN',"A55:A100");


>>test


error: xlsopen.m: write mode requested but file test.xlsx is not writable


Steven Weinberg <wstevena>
Thu 03 Nov 2016 08:07:29 PM UTC, comment #14: 

Thank you so much. I did have the windows package all the time, I just didn't see it when I ran 'pkg list" because it was after the page break. So now I have the 'COM' interface.  I tried to get the POI support (as OPENXLS was firewalled). This is what happened

chk_spreadsheet_support ('...\poi-3.15',2)

(OCT interface... OK, included in io package)

Checking Excel/ActiveX/COM... OK.

1. Checking Octave's Java support... OK.
2. Checking Java dependencies...
  Checking Java JRE presence.... OK, found one.
No Java support found.
No Java support found.
ans =          1

So, it does not appear to have worked. 


Steven Weinberg <wstevena>
Thu 03 Nov 2016 05:52:06 PM UTC, comment #13: 

Steve,

(yeah firewalls etc. Our IT dept. is also strict but they'll always help us when we need stuff from the web we cannot d/ld ourselves.)

I see you run Octave on Windows. How did you install Octave then? the windows package is included in the Windows installer.
"pkg load windows"
should do the trick.

Or could you download windows-1.2.4.tar.gz at home to a thumb drive and then install it at work from there? or email it to your work email?
AFAIK we rarely put up complete packages etc. here, to eliminate chances of outdated cruft being picked up later on.

As to not being able to read the .xls file, is that because you cannot download & install Java support libs? ("install" means merely copying a java .jar file)
If you can, I'd try the OpenXLS interface first - the fastest and it's just one file: see http://openxls.sf.net (yep, sourceforge)
Apache POI is superior but needs 3 (for .xls) + another 2 (for .xlsx) .jar files. See http://poi.apache.org/download.html

If you put all the .jar files in one place, simply "load" them using:
chk_spreadsheet_support ('/full/path/to/subdir/with/jar/libraries', 2)
(line wrap!)
and it should work. chk_spreadsheet_support is in the io package.

In the mean time I'll search further for how to cope with the "illegal" character in XML.

Philip Nienhuis <philipnienhuis>
Group Member
Thu 03 Nov 2016 05:48:50 PM UTC, comment #12: 

Just to clarify, test.xlsx was created by opening test.xls in Excel, then saving it as test.xlsx.  The illegal XML characters were created by Excel based on spreadsheet cells that contained text which included those characters.

Steven Weinberg <wstevena>
Wed 02 Nov 2016 11:41:15 PM UTC, comment #11: 

@Philip

I created test.xlsx by opening one of the .xls files I use in Matlab, then deleting all sheets except main and wmat*.  I then saved the file in the xlsx format. The original .xls file may have had some Matlab artifacts, but definitely none from Octave.

I couldn't get Octave to open an .xls file, which is why I saved it in as an xlsx. Perhaps if I could use the 'COM' interface I would be able to read and write to .xls, as the Matlab does. As I mentioned in comment #3, I am firewalled from accessing octave.sourceforge, as that site is completely blocked at work. I can't even reach the domain. If the windows package file were to find itself uploaded here, I would then have access to it.




Steven Weinberg <wstevena>
Wed 02 Nov 2016 10:54:23 PM UTC, comment #10: 

You can get & install the windows package yourself with a simple

pkg install -forge windows

The bug in OCT should be fixed, but I'm curious as to your answer on my question in comment #9.
Notably I wonder if you made the spreadsheet with io package < 1.4.1

Philip Nienhuis <philipnienhuis>
Group Member
Wed 02 Nov 2016 10:34:07 PM UTC, comment #9: 

@Steve:
How did you create the test.xlsx file?
I find that the sharedStrings.xml in the archive (= .xlsx file) contains illegal XML characters (i.e., ">", "&"); these should have been escaped alredy in the original xml file in test.xlsx.
Intriguingly Excel happily accepts those but after rewriting the file it chokes on them. LibreOffice simply skips the pertinent text strings.

I can fix this with a costly regexprep call; but those characters shouldn't have been there in the first place so in principle a regexprep shouldn't be needed.

In the mean time I found & fixed the underlying issue. A final fix depends on how to make Excel / LibreOffice cope with illegal XML chars.

Philip Nienhuis <philipnienhuis>
Group Member
Wed 02 Nov 2016 09:41:39 PM UTC, comment #8: 

When running the same script in Matlab, wnames is a 3x1 cell, whereas as you noted it is a 1x3 cell in Octave. Here are the workspace variables for each:

Matlab:

intfname 'test.xlsx'
poswmat [2,3,4]
sheets 1x4 cell
status 'Microsoft Excel Spreadsheet'
wnames 3x1 cell

Octave:

intfname 'test.xlsx'
poswmat double 3x1 ...
sheets cell 4x2
status 'Microsoft Excel Spreadsheet'
wnames cell 1x3

Steven Weinberg <wstevena>
Wed 02 Nov 2016 08:57:01 PM UTC, comment #7: 

I ran this change to the script:


rng = sprintf ("A55:%s55", num2col (numel(wnames)));
xlswrite(intfname,wnames,'MAIN',rng);


There was no error in Octave. However when I opened the file test.xlsx it was corrupted.  I gave me the following error:


<?xml version="1.0" encoding="UTF-8" standalone="true"?>

-<recoveryLog xmlns="http://schemas.openxmlformats.org/spreadsheetml/2006/main">

<logFileName>error040480_07.xml</logFileName>

<summary>Errors were detected in file 'D:\GVAR_Toolbox2.0_octave\GVAR_Toolbox2.0\test.xlsx'</summary>


-<removedParts summary="Following is a list of removed parts:">

<removedPart>Removed Part: /xl/sharedStrings.xml part with XML error. (Strings) The name in the end tag of the element must match the element type in the start tag. Line 2, column 1071.</removedPart>

</removedParts>


-<removedRecords summary="Following is a list of removed records:">

<removedRecord>Removed Records: Cell information from /xl/worksheets/sheet1.xml part</removedRecord>

<removedRecord>Removed Records: Cell information from /xl/worksheets/sheet3.xml part</removedRecord>

<removedRecord>Removed Records: Cell information from /xl/worksheets/sheet4.xml part</removedRecord>

</removedRecords>

</recoveryLog>


Matlab actually places wnames in cells A55:A57.

If you could upload the windows-1.2.4.tar.gz file, I could access it from this site and install it.  Then I could determine whether my problems are resolved with the 'COM' interface.

Steven Weinberg <wstevena>
Wed 02 Nov 2016 06:31:37 PM UTC, comment #6: 

Should read:
"(w*n*ames will be written to A55:C5 then - is that what you want?)"

Philip Nienhuis <philipnienhuis>
Group Member
Wed 02 Nov 2016 04:16:40 PM UTC, comment #5: 

Ah, "wnames" is a 1x3 rather than a 3x1 cellstr array. Sorry for the confusion.
Repeat with:

rng = sprintf ("A55:%s55", num2col (numel (wnames)));
xlswrite (intfname, wnames, 'MAIN', rng);


(wames will be written to A55:C5 then - is that what you want?)

As to "Codes": that must be something in your local setup. Any idea where that comes from?

Now I can see that you used the OCT interface. I can confirm what you see in the original report with the OCT interface; with all other .xlsx-capable interfaces (COM, POI, UNO) it works fine.

Philip Nienhuis <philipnienhuis>
Group Member
Wed 02 Nov 2016 02:02:44 PM UTC, comment #4: 

I tried your idea of computing the range:

rng = sprintf ("A55:A%d", numel (wnames) + 54);
xlswrite(intfname,wnames,'MAIN',rng)


warning: load_path: Codes: No such file or directory
warning: xlswrite - array truncated to 3 by 1 to fit in range A55:A57
warning: called from
    xlswrite at line 184 column 5
    test at line 13 column 1
warning: load_path: Codes: No such file or directory
warning: load_path: Codes: No such file or directory
warning: called from
    __OCT_spsh_close__ at line 42 column 7
    xlsclose at line 121 column 9
    xlswrite at line 202 column 11
    test at line 13 column 1


Steven Weinberg <wstevena>
Wed 02 Nov 2016 01:26:24 PM UTC, comment #3: 

Thank you for investigating this.  I get a 0 when I run the chk_spreadsheet_support function.  Indeed, when I explicitly try to force 'COM', it says COM is not supported.

I am firewalled from the sourceforge.net site, so I am not able to download the windows package. I even tried emailing the package from my personal account and that was also blocked.


Steven Weinberg <wstevena>
Tue 01 Nov 2016 10:58:09 PM UTC, comment #2: 

If required you can compute the range (should also work in Matlab):

rng = sprintf ("A55:A%d", numel (wnames) + 54);

  ...... % other code

xlswrite (intfname, wnames, 'MAIN', rng);


Philip Nienhuis <philipnienhuis>
Group Member
Tue 01 Nov 2016 10:55:15 PM UTC, comment #1: 

(Exactly which program works fine in Matlab? the code snippet you gave, or chknmrange.m?)

What interface is reported? if you see no mention, simply run
chk_spreadsheet_support (in the io package) and report back its output (a numeric).

I'll have a look later on, no time now.

BTW I ran your example here and got no errors (using COM interface).
I noted the warning, but that is according to the docs: the io package xlsread won't expand the range you specify automatically. You need to specify a sufficiently large range, maybe A55:A100 or so. If wnames is smaller, xlsread just writes the wnames entries and won't touch the other cells within that range - unlike Matlab which screws them up.

Philip Nienhuis <philipnienhuis>
Group Member
Tue 01 Nov 2016 08:47:05 PM UTC, original submission:  

I am using the IO package version 2.4.3 with the patched chknmrange.m file, as provided by Philip.  This program works fine in Matlab.

Here is the test script;


intfname='test.xlsx';
[status,sheets] = xlsfinfo(intfname);
poswmat=find(strncmp(sheets, 'wmat', 4));
wnames=sheets(poswmat)';
xlswrite(intfname,wnames,'MAIN','A55');



>> test

warning: xlswrite - array truncated to 1 by 1 to fit in range A55
warning: called from
    xlswrite at line 184 column 5
    test at line 12 column 1



When I open the corrupted spreadsheet I get:

++verbatim
-<recoveryLog xmlns="http://schemas.openxmlformats.org/spreadsheetml/2006/main">

<logFileName>error040480_05.xml</logFileName>

<summary>Errors were detected in file 'D:\GVAR_Toolbox2.0_octave\GVAR_Toolbox2.0\test.xlsx'</summary>


-<removedParts summary="Following is a list of removed parts:">

<removedPart>Removed Part: /xl/sharedStrings.xml part with XML error. (Strings) The name in the end tag of the element must match the element type in the start tag. Line 2, column 1071.</removedPart>

</removedParts>


-<removedRecords summary="Following is a list of removed records:">

<removedRecord>Removed Records: Cell information from /xl/worksheets/sheet1.xml part</removedRecord>

<removedRecord>Removed Records: Cell information from /xl/worksheets/sheet3.xml part</removedRecord>

<removedRecord>Removed Records: Cell information from /xl/worksheets/sheet4.xml part</removedRecord>

</removedRecords>

</recoveryLog>
--verbatim



Steven Weinberg <wstevena>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #38858:  test.xlsx added by wstevena (503KiB - application/vnd.openxmlformats-officedocument.spreadsheetml.sheet - The first file is before running the program. The second is after.)
file #38859:  test(corrupt).xlsx added by wstevena (399KiB - application/vnd.openxmlformats-officedocument.spreadsheetml.sheet - The first file is before running the program. The second is after.)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by wstevena (Submitted the item)
  • -email is unavailable- added by wstevena
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 10 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-11-09 philipnienhuis StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2016-11-03 philipnienhuis StatusNeed Info Ready For Test
    2016-11-02 philipnienhuis StatusConfirmed Need Info
    2016-11-02 philipnienhuis Item GroupMatlab Compatibility Incorrect Result
        StatusNone Confirmed
        Assigned toNone philipnienhuis
    2016-11-01 wstevena Attached File- Added test.xlsx, #38858
        Attached File- Added test(corrupt).xlsx, #38859
        Carbon-Copy- Added -email is unavailable-

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code