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/
Created attachment 145750 [details] Example of bug in database
Confirm. Version: 6.2.0.0.alpha0+ Build ID: 49c87270f7176312806d1759967c247a312f0acf CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: gtk2;
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.
Dear Robert Simpson, 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 with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. 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) from https://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: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
(In reply to QA Administrators from comment #4) > Dear Robert Simpson, > > ... > Warm Regards, > QA Team > > MassPing-UntouchedBug Yes the bug is still apparently present, as demonstrated by the attachment to comment 1. Ubuntu 20.04 LO Version: 6.4.6.2 Build ID: 1:6.4.6-0ubuntu0.20.04.1 CPU threads: 8; OS: Linux 5.8; UI render: default; VCL: gtk3; Locale: en-GB (en_GB.UTF-8); UI-Language: en-GB Calc: threaded Tracing back, the bug was present in 6.2.1 (appimage), the first version with Firebird as standard, I believe. It also fails in 6.1.6. I don't know when Firebird was first supported. 3.3 cannot connect to the database.
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
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.
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?
@Julien, I thought you might be interested in this issue
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 ***