<html>
<head>
<base href="https://bugs.documentfoundation.org/">
</head>
<body><span class="vcard"><a class="email" href="mailto:serval2412@yahoo.fr" title="Julien Nabet <serval2412@yahoo.fr>"> <span class="fn">Julien Nabet</span></a>
</span> changed
<a class="bz_bug_link
bz_status_NEW "
title="NEW - Error while saving the table design"
href="https://bugs.documentfoundation.org/show_bug.cgi?id=131295">bug 131295</a>
<br>
<table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>What</th>
<th>Removed</th>
<th>Added</th>
</tr>
<tr>
<td style="text-align:right;">CC</td>
<td>
</td>
<td>lionel@mamane.lu
</td>
</tr></table>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - Error while saving the table design"
href="https://bugs.documentfoundation.org/show_bug.cgi?id=131295#c4">Comment # 4</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - Error while saving the table design"
href="https://bugs.documentfoundation.org/show_bug.cgi?id=131295">bug 131295</a>
from <span class="vcard"><a class="email" href="mailto:serval2412@yahoo.fr" title="Julien Nabet <serval2412@yahoo.fr>"> <span class="fn">Julien Nabet</span></a>
</span></b>
<pre>The problem isn't Firebird only, depending of the old/new field, length updates
or not.
Following bt retrieved previously, I noticed this commit:
<a href="https://cgit.freedesktop.org/libreoffice/core/commit/?id=465cf674e8118922029e7e117fdae91e887bcee0">https://cgit.freedesktop.org/libreoffice/core/commit/?id=465cf674e8118922029e7e117fdae91e887bcee0</a>
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
<a href="https://opengrok.libreoffice.org/xref/core/dbaccess/source/ui/tabledesign/FieldDescriptions.cxx?r=a41f9b3a#181">https://opengrok.libreoffice.org/xref/core/dbaccess/source/ui/tabledesign/FieldDescriptions.cxx?r=a41f9b3a#181</a>
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?</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>