(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.
--
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 Productivity Suite:
Confirmed
Status in “libreoffice” package in Ubuntu:
Confirmed
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 : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
