After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 124932 - Dubious data in IF equation causes loss of data
Dubious data in IF equation causes loss of data
Status: RESOLVED DUPLICATE of bug 124930
Product: Gnumeric
Classification: Applications
Component: Main System
1.1.x
Other Linux
: Immediate blocker
: ---
Assigned To: Jody Goldberg
Jody Goldberg
Depends on:
Blocks:
 
 
Reported: 2003-10-18 22:25 UTC by danielm
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Gnumeric spreadsheet (created 21 months ago and modified with various versions of gnumeric) (25.36 KB, application/octet-stream)
2003-10-22 23:51 UTC, danielm
Details

Description danielm 2003-10-18 22:25:23 UTC
An equation of the form if(D5+E5,D5+E5," ") causes subsequent file saves to
fail.

The invoking terminal displays 'xmlEncodeEntitiesReentrant : input not UTF-8'
upon saving. Somehow the file reverts more or less back to the stage at
which the dodgy expression was entered into the sheet (ie all subseqeunt
work is lost!).

What I was trying to do was to display the sum of two cells, only if the
cells contained valid data, otherwise I wanted to leave the cell blank (as
opposed to showing zero as the cell was formatted as a 2 digit number). The
equation editor finally allowed the above form and so I thought it was
legal - it certainly behaved how I wanted on the screen, but not to the disk!
Comment 1 Morten Welinder 2003-10-19 14:06:47 UTC
I cannot reproduce this.  Can you come up with a specific and detailed
recipe for getting this problem to occur?
Comment 2 Jody Goldberg 2003-10-20 03:18:11 UTC
Ideally a precise recipe of what you type and what locale you are
running in.

What version are you using ?
Comment 3 Jody Goldberg 2003-10-22 21:26:55 UTC
Please give us more information here.
I'm loath to close these reports as 'insufficient information' but I also can
not replicate them and do not want to hold up the release if they're phantom.
Comment 4 danielm 2003-10-22 23:49:17 UTC
Sorry for the delay, the locale question led me to my old environment
out of the backup disk.

1. I simply added a cell entry =if(D5+E5,D5+E5," "), but what I've
since observed is unstable too, I'll attach the file next. You can try
the changes on the third sheet ("1 Bank"). On the night in question I
did lots of reformatting (adding shading, deleting shading, changing
column widths) and generally mucking about with that sheet and finally
saved after about 25 mins. When I later re-loaded the file my changes
subsequent to the equation entry had been lost.

2. I appear to be running in a locale-less environment! The file was
previously modified on an RH-7.3 system with gnumeric-1.0.5-3 and
LC_ALL=en_US in force (originally created on a 0.6?? version of
gnumeric around Jan '02). The current environment is SL-9.0.

3. I've tried setting LC_ALL to en_US & properly to en_GB.UTF-8. Same
complaint to the terminal (which I think doesn't relate to this bug).

4. I see differing behaviour depending if I start a completely new
file (and just add a couple of cells) and if I use my original file.
With the original file, the save & re-load changes the cell contents
from =if(D5+E5,D5+E5," ") to =if(D5+E5,D5+E5). That doesn't happen
when testing with a totally blank file.

5. I'm not sure that this bug is repeatable enough to warrant tracking
down.
Comment 5 danielm 2003-10-22 23:51:24 UTC
Created attachment 20871 [details]
Gnumeric spreadsheet (created 21 months ago and modified with various versions of gnumeric)
Comment 6 Jody Goldberg 2003-10-24 13:34:40 UTC
You're just seeing random results dues to the corrupt data in there.
We need to be more explicit warning about these problems when we see
them, but I suspect that all the random behavior you are seeing stems
from the corrupt formats.

*** This bug has been marked as a duplicate of 124930 ***