Bug 120640 - FIREBIRD: CHAR() - Values not appearing in base listbox with value list
Summary: FIREBIRD: CHAR() - Values not appearing in base listbox with value list
Status: RESOLVED DUPLICATE of bug 147893
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
6.1.2.1 release
Hardware: All All
: medium normal
Assignee: Andreas Heinisch
URL: https://github.com/FirebirdSQL/firebi...
Whiteboard:
Keywords:
Depends on:
Blocks: Database-Firebird-Default
  Show dependency treegraph
 
Reported: 2018-10-16 10:41 UTC by Robert Simpson
Modified: 2022-04-13 10:12 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
Example of bug in database (11.20 KB, application/vnd.oasis.opendocument.database)
2018-10-16 10:44 UTC, Robert Simpson
Details
Valuefields are not displayed in field "S" of form (18.10 KB, application/vnd.sun.xml.base)
2019-02-20 09:48 UTC, software.v9onn
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Simpson 2018-10-16 10:41:16 UTC
Description:
In Base with the firefox engine, when a listbox governed by a value-list links to a fixed width field (CHAR), the existing value is not not displayed in the form.
When the field is variable width (VARCHAR), values display correctly, and when the list is governed by sql statement, the values are displayed correctly.


Steps to Reproduce:
1.Create new database with 1 table with 2 fields, CHAR and VARCHAR
2.Create form displaying fields in listboxes with Type 'Valuelist', and specifying list in 'List entries'
3.

Actual Results:
VARCHAR field displays correctly, CHAR field does not
(Fields are, however, updated).
(Type 'sql' lists governed by 'List contents' display correctly.)

Expected Results:
List values should always display.


Reproducible: Always


User Profile Reset: No



Additional Info:
Example data base attached at https://ask.libreoffice.org/en/question/168876/values-not-appearing-in-base-listbox/
Comment 1 Robert Simpson 2018-10-16 10:44:42 UTC
Created attachment 145750 [details]
Example of bug in database
Comment 2 raal 2018-10-16 16:42:43 UTC
Confirm. Version: 6.2.0.0.alpha0+
Build ID: 49c87270f7176312806d1759967c247a312f0acf
CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: gtk2;
Comment 3 software.v9onn 2019-02-20 09:48:56 UTC
Created attachment 149437 [details]
Valuefields are not displayed in field "S" of form

Similar problem with boolean fields and valuelists. Example attached: the field "S" is only displayed when it has focus.
Comment 4 QA Administrators 2021-02-20 04:05:41 UTC Comment hidden (obsolete)
Comment 5 Robert Simpson 2021-02-22 20:38:37 UTC Comment hidden (obsolete)
Comment 6 Andreas Heinisch 2022-04-12 18:38:33 UTC
In firebird::mallocSQLVAR [1] the string will be allocated. In the case of char (SQL_TEXT) the length is 12 even if the field only contains 3. In OResultSet::retrieveValue [2] the OUString will be created using that exact length. This leads to this error since the list box compares "ant" with "ant   
   ". Could it be that retrieves the maximum size in bytes for a char?

[1] https://opengrok.libreoffice.org/xref/core/connectivity/source/drivers/firebird/Util.cxx?r=3a88b513#296
[2] https://opengrok.libreoffice.org/xref/core/connectivity/source/drivers/firebird/ResultSet.cxx?r=a9c8ac36#584
Comment 7 Robert Großkopf 2022-04-12 19:32:38 UTC
Seems this is the same bug as https://bugs.documentfoundation.org/show_bug.cgi?id=147893.

CHAR() will be set to the 4th length of the string, which is defined.
So you could change the list fields by adding 9 spaces to each entry, because 9 spaces could also been seen in the table.

This is a special Firebird bug.
Comment 8 Andreas Heinisch 2022-04-12 20:23:55 UTC
However, in the length field in the edit table view, the correct length is show. Maybe during the creation of the table the spurious size will be added?
Comment 9 Xisco Faulí 2022-04-13 08:31:17 UTC
@Julien, I thought you might be interested in this issue
Comment 10 Alex Thurgood 2022-04-13 10:12:00 UTC
Wouldn't usually mark an earlier bug report as a DUP of a later one, but the later one has a clearer description, and seemingly goes to the root of the problem.

*** This bug has been marked as a duplicate of bug 147893 ***