Something for 'spreadsheet'?

IMHO not for spreadsheet but for base.

clu->fst: why base? this seems to be a calc specific setting and also fails in
writer, like described in second paragraph.

(i would guess: anything with the numberformatter?)

When pasting HTML into Writer, the raw number is transferred and interpreted
differently. But what do you mean by pasting into the database document anyway?
Into a table view, or a form, or what?

After you have copied it in Calc, goto the open Base-document, choose category
"Tables", open menu "Edit", choose "Paste Special". You get the import dialog
starting with "Copy Table". In step "Type formatting" select field type "Date"
for that column.

regina, do you copy the two cells in question only, or do you also have "header
cells"? When copying the mere cells only, then they're used as column names, so
no data is copied. When also copying "header cells", then I can't really
reproduce your issue, since I get some "wrong data type" message. Hmm.
I'd like to reproduce this issue, to form an opinion myself ....

I'll attach a step-by-step instruction in pictures.

Created attachment 35290 [details]
import table from Calc into Base

fs->oj: at least for the HTML part, this can probably be fixed:
OHTMLReader::NextToken evaluates the "sdval" attribute of a table cell. Now this
contains the (number-formatter-dependent) numeric value only, which cannot
intepreted without having the number formatter - and its NullDate, in
particular. Since we do not have this formatter, I suggest that
OHTMLReader::NextToken uses another approach:

the "sdnum" attribute of the table cell describes the number format of the
string. We should use to to translate the cell content into a numeric value. If
we then not only remember the textual representation (m_sNextToken), but the
already-converted numeric representation, together with the number format, we
should be on the safe side (and also spare
ODatabaseExport::insertValueIntoColumn some work).

Since I consider this data corruption (the pasted data is different from the
original data) during collaboration of OOo applications, I target it for the
next maintainance release.


fs->regina: I'm adjusting the summary to reflect that this is about HTML and
Base only. Sorry, but there are reasons [1] why multiple problems per issue are
difficult to handle. At least the Writer/Web part is completely different from
this one here (and much less severe, IMO). The Base/RTF part is probably (after
I examined the source) also different, and also less severe IMO since the
default format for pasting is HTML. So, if you want those other incarnations to
be fixed, too, I encourage you to submit new issues. Sorry and thanks :)

[1] http://qa.openoffice.org/issue_handling/basic_rules.html#one_per_issue

Fixed in cws dba203c

Please verify. Thanks.

.

.

verified in cws dba203c

find more information about this CWS, like when it is available in the master
builds, in EIS, the Environment Information System:
http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=SRC680%2Fdba203c

Hi,

this is fixed in the current master. The current master is available at
http://download.openoffice.org/680/index.html

I close this issue now.

Bye Marc

*** Issue 61949 has been marked as a duplicate of this issue. ***

*** Issue 61949 has been marked as a duplicate of this issue. ***

*** Issue 61949 has been marked as a duplicate of this issue. ***