Launchpad has imported 12 comments from the remote bug at https://bugs.documentfoundation.org/show_bug.cgi?id=49054.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2012-04-22T08:42:15+00:00 Sandra Farnedi wrote: When I define a table field in LbreOfficeBase I notice that the following field types NUMERIC, DECIMAL, FLOAT, VARCHAR, VARCHAR_IGNORECASE, inherit the latest set length, that is: when I add a field it is set to VARCHAR (100), if I change it to FLOAT its length is automatically set to 17, if I come back to VARCHAR, the field length is not set back to 100, but still remains 17. Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/986880/comments/0 ------------------------------------------------------------------------ On 2012-04-22T11:05:42+00:00 Vinner21 wrote: [Reproducible] with "LibreOffice 3.5.2.2 - GNU/Linux Ubuntu 11.10,English UI" Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/986880/comments/1 ------------------------------------------------------------------------ On 2012-08-27T19:06:43+00:00 Iplaw67-h wrote: *** Bug 53591 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/986880/comments/10 ------------------------------------------------------------------------ On 2012-08-27T19:09:30+00:00 Iplaw67-h wrote: Changing version to 3.4.4 as this is the earliest release in which I can reproduce the behaviour. Alex Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/986880/comments/12 ------------------------------------------------------------------------ On 2012-08-27T19:12:36+00:00 Iplaw67-h wrote: Changed title to better reflect situation Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/986880/comments/14 ------------------------------------------------------------------------ On 2014-07-24T07:31:27+00:00 julien2412 wrote: On pc Debian x86-64 with master sources updated today, I could reproduce this. After a gdb session, it seems the problem is here: 224 if ( _pType->aCreateParams.isEmpty() ) 225 { 226 SetPrecision(_pType->nPrecision); 227 SetScale(_pType->nMinimumScale); 228 } http://opengrok.libreoffice.org/xref/core/dbaccess/source/ui/tabledesign/FieldDescriptions.cxx#224 Indeed, the types which have the problem have _pType->aCreateParams not empty and so don't enter the if block. NUMBER => "PRECISION,SCALE" VARCHAR => "LENGTH" etc. Lionel: What's the purpose of this if block? Could it be removed? Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/986880/comments/16 ------------------------------------------------------------------------ On 2014-07-24T07:34:41+00:00 julien2412 wrote: Forgot to say I was looking "precision" because of this line of the same file: 1422 if( pLength ) 1423 pLength->SetText( OUString::number(pFieldDescr->GetPrecision()) ); See http://opengrok.libreoffice.org/xref/core/dbaccess/source/ui/control/FieldDescControl.cxx#1422 Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/986880/comments/18 ------------------------------------------------------------------------ On 2014-07-24T08:12:51+00:00 julien2412 wrote: If we suppose_pType->aCreateParams.isEmpty() is useful, here's a naive patch: diff --git a/dbaccess/source/ui/tabledesign/FieldDescriptions.cxx b/dbaccess/source/ui/tabledesign/FieldDescriptions.cxx index 65fb772..d3495a8 100644 --- a/dbaccess/source/ui/tabledesign/FieldDescriptions.cxx +++ b/dbaccess/source/ui/tabledesign/FieldDescriptions.cxx @@ -221,7 +221,7 @@ void OFieldDescription::FillFromTypeInfo(const TOTypeInfoSP& _pType,bool _bForce SetScale(::std::min<sal_Int32>(GetScale() ? GetScale() : DEFAULT_NUMERIC_SCALE,_pType->nMaximumScale)); } } - if ( _pType->aCreateParams.isEmpty() ) + if ( _pType->aCreateParams.isEmpty() || _bForce ) { SetPrecision(_pType->nPrecision); SetScale(_pType->nMinimumScale); since _bReset seems to deal with SetFormatKey and SetControlDefault, see lines 176..180 of this same file. Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/986880/comments/20 ------------------------------------------------------------------------ On 2014-07-24T08:36:19+00:00 Lionel Elie Mamane wrote: (In reply to comment #7) > If we suppose_pType->aCreateParams.isEmpty() is useful, here's a naive patch: > diff --git a/dbaccess/source/ui/tabledesign/FieldDescriptions.cxx > b/dbaccess/source/ui/tabledesign/FieldDescriptions.cxx > index 65fb772..d3495a8 100644 > --- a/dbaccess/source/ui/tabledesign/FieldDescriptions.cxx > +++ b/dbaccess/source/ui/tabledesign/FieldDescriptions.cxx > @@ -221,7 +221,7 @@ void OFieldDescription::FillFromTypeInfo(const > TOTypeInfoSP& _pType,bool _bForce > SetScale(::std::min<sal_Int32>(GetScale() ? > GetScale() : DEFAULT_NUMERIC_SCALE,_pType->nMaximumScale)); > } > } > - if ( _pType->aCreateParams.isEmpty() ) > + if ( _pType->aCreateParams.isEmpty() || _bForce ) > { > SetPrecision(_pType->nPrecision); > SetScale(_pType->nMinimumScale); To me, it looks like when changing type, the "switch" statement just before in the code is in charge (when the type changed, thus bForce is true, even if _bForce is not) of setting the default values. I'd recommend looking through it, what happens when the bug is hit? But actually, it is not immediately obvious to me what the best behaviour should be here, actually. The bug reporter seems to suggest "always reset to the type default, for *any* type change". But keeping the same length (precision?) kinda makes sense, too. E.g. when going from FLOAT(17) to VARCHAR(n), well, a FLOAT(17) "fits" in a VARCHAR(17) (or is it VARCHAR(18) to account for the decimal separator? Need to look at definitions...), so one could argue that n=17 (or 18 / ...) is a rather good heuristic. A very quick glance at the code suggests that maybe that's what is being done, very much on purpose. Similarly, when changing from NUMERIC to DECIMAL or vice-versa, keeping the same precision and scale again makes sense to me... Similarly, "in a perfect world" switching from INTEGER(10) to NUMERIC, I'd say that NUMERIC(10, 0) is as good a guess than any. I'd also keep the previous length when switching between CHAR, VARCHAR, VARCHAR_IGNORECASE, etc, etc. Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/986880/comments/22 ------------------------------------------------------------------------ On 2014-07-29T19:12:53+00:00 julien2412 wrote: Created attachment 103650 bts After having put a break on SetPrecision, I retrieved differents bts showing 2 tests: 1) Varchar => Numeric (where precision isn't changed) which call 2 times SetPrecision() 2) Numeric => Real (where precision changed) which call 3 times SetPrecision() (because _pType->aCreateParams.isEmpty() - see my previous comment - is true) If it can help... Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/986880/comments/24 ------------------------------------------------------------------------ On 2015-01-03T17:39:49+00:00 Iplaw67-h wrote: Adding self to CC if not already on Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/986880/comments/26 ------------------------------------------------------------------------ On 2016-09-20T10:18:59+00:00 Qa-admin-q wrote: ** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.1.5 or 5.2.1 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20160920 Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/986880/comments/28 ** Changed in: df-libreoffice Status: Unknown => Confirmed ** Changed in: df-libreoffice Importance: Unknown => Medium -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to libreoffice in Ubuntu. https://bugs.launchpad.net/bugs/986880 Title: [Upstream] field length inherited Status in LibreOffice: Confirmed Status in libreoffice package in Ubuntu: Incomplete Bug description: When I define a table field in LbreOfficeBase I notice that the following field types NUMERIC, DECIMAL, FLOAT, VARCHAR, VARCHAR_IGNORECASE, inherit the latest set length, that is: when I add a field it is set to VARCHAR (100), if I change it to FLOAT its length is automatically set to 17, if I come back to VARCHAR, the field length is not set back to 100, but still remains 17. ProblemType: Bug DistroRelease: Ubuntu 12.04 Package: libreoffice-core 1:3.5.2-2ubuntu1 ProcVersionSignature: Ubuntu 3.2.0-23.36-generic-pae 3.2.14 Uname: Linux 3.2.0-23-generic-pae i686 ApportVersion: 2.0.1-0ubuntu5 Architecture: i386 CasperVersion: 1.315 Date: Sun Apr 22 13:13:28 2012 ExecutablePath: /usr/lib/libreoffice/program/soffice.bin LiveMediaBuild: Edubuntu 12.04 LTS "Precise Pangolin" - Beta i386 (20120420) ProcEnviron: PATH=(custom, no user) LANG=it_IT.UTF-8 SHELL=/bin/bash SourcePackage: libreoffice UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/df-libreoffice/+bug/986880/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
