[Libreoffice-bugs] [Bug 131295] Error while saving the table design

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=131295

Julien Nabet <serval2412 at yahoo.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |lionel at mamane.lu

--- Comment #4 from Julien Nabet <serval2412 at yahoo.fr> ---
The problem isn't Firebird only, depending of the old/new field, length updates
or not.

Following bt retrieved previously, I noticed this commit:
https://cgit.freedesktop.org/libreoffice/core/commit/?id=465cf674e8118922029e7e117fdae91e887bcee0
INTEGRATION: CWS apps61beta2 (1.11.2); FILE MERGED
2003/04/01 10:56:20 oj 1.11.2.1: #108512# correct precision handling

-                    if ( _pType->nPrecision && _pType->nMaximumScale )
-                    {
-                        SetPrecision(nPrec ? nPrec :
DEFAULT_NUMERIC_PRECSION);
+                    if ( _pType->nPrecision )
+                        SetPrecision(::std::min<sal_Int32>(nPrec ? nPrec :
DEFAULT_NUMERIC_PRECSION,_pType->nPrecision));
+                    if ( _pType->nMaximumScale )
                         SetScale(::std::min<sal_Int32>(GetScale() ? GetScale()
: DEFAULT_NUMERIC_SCALE,_pType->nMaximumScale));
-                    }
-                    else if ( _pType->nPrecision )
-                       
SetPrecision(::std::min<sal_Int32>(nPrec,_pType->nPrecision));

Lionel: the whole "switch" in OFieldDescription::FillFromTypeInfo seems a bit
strange
See
https://opengrok.libreoffice.org/xref/core/dbaccess/source/ui/tabledesign/FieldDescriptions.cxx?r=a41f9b3a#181

Why we would take into account these elements(in addition to the precision of
new type):
- the precision from previous type
- a default value
- a min of a combination of these?
- new type (do we really need all this switch?)

I mean, in case of bForce is true, why couldn't we just use precision of new
element and only take the previous one (or a by default one,
DEFAULT_VARCHAR_PRECISION/DEFAULT_OTHER_PRECISION) if there's no precision
defined for new element?

Remark as a side part:
About DEFAULT_VARCHAR_PRECISION/DEFAULT_OTHER_PRECISION, we could check a
precision has been defined with an assert. I mean perhaps we should force to
define precision for all types of all DB drivers?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20200312/bd35b90f/attachment.htm>