Description: Using the (Firebird) LIST function in LibreOffice Base, the result contains various number of white square (like ⬜) characters. Steps to Reproduce: 1. Creating a table (Table) ID INTEGER Data INTEGER 2. Filling with some data ID Data 1 11 1 12 1 13 2 201 2 202 2 203 3 3001 3 3002 3 3003 3. Making a query with the following sql command: SELECT "ID", LIST( "Data", ' / ' ) FROM "Table" GROUP BY "ID" Actual Results: ID LIST 1 11⬜ / 12⬜ / 13⬜ 2 201 / 202 / 203 3 3001 / ⬜3002 / ⬜3003 Expected Results: ID LIST 1 11 / 12 / 13 2 201 / 202 / 203 3 3001 / 3002 / 3003 Reproducible: Always User Profile Reset: No OpenGL enabled: Yes Additional Info: LibreOffice Base 6.1.1.2 (x64) / JavaSE 10.0.2 (x64) / Windows 10 Same behavior occur with different - different data types (of "Data" column), - java versions, - language settings. This "bug" is not exist in Windows7, Ubuntu 18.04, maybe only in Windows10.
Created attachment 145186 [details] test file with list query I can't confirm because as the reporter states it works for under Ubuntu 18.04 But for anyone with Windows 10, here is an example file with a query.
No repro either with: Version: 6.1.1.2 Build ID: 5d19a1bfa650b796764388cd8b33a5af1f5baa1b Threads CPU : 4; OS : Mac OS X 10.13.6; UI Render : par défaut; Locale : fr-FR (fr_FR.UTF-8); Calc: group threaded
A conversion of the BLOB data of LIST to VARCHAR removes the ⬜ characters...
I reproduce with : Version: 6.1.0.3 (x64) Build ID: efb621ed25068d70781dc026f7e9c5187a4decd1 Threads CPU : 4; OS : Windows 10.0; UI Render : par défaut; Locale : fr-FR (fr_FR); Calc: group threaded Version: 6.2.0.0.alpha0+ (x64) Build ID: c8481c8a43ce2544275b2d70ef29a8b0cb157732 CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-10-11_00:41:23 Locale: fr-FR (fr_FR); Calc: threaded Microsoft Windows 10 Version 1803
Dear Szilárd Vezér, Could you please try to reproduce it with a master build from http://dev-builds.libreoffice.org/daily/master/ ? You can install it alongside the standard version. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the master build
On Win10 with master sources updated today, I could reproduce this.
I tried to install Firebird 3.0.4 Win to give a try on Firebird directly but know too few Firebird to give it a try. Indeed, I tested isqltool with https://firebirdsql.org/manual/isql-invoke.html but it doesn't work.
Dear Szilárd Vezér, 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
It may be already be fixed with tdf#144230 (put in see also). You can give a try to a daily build from https://dev-builds.libreoffice.org/daily/master/Win-x86_64@tb77-TDF/current/ (of course, it's just for the test since it's a dev version).
(In reply to Julien Nabet from comment #9) > It may be already be fixed with tdf#144230 (put in see also). No, I also saw *zero bytes* added to LIST output; and given that I don't know much about how it should work, I thought it's how the BLOB should look like. Looks like I need to take a look at it deep :-)
(In reply to Mike Kaganski from comment #10) > (In reply to Julien Nabet from comment #9) > > It may be already be fixed with tdf#144230 (put in see also). > > No, I also saw *zero bytes* added to LIST output; and given that I don't > know much about how it should work, I thought it's how the BLOB should look > like. Looks like I need to take a look at it deep :-) Hehe, I noticed your recent great work on Firebird, knowing that there are very few commits about Base part, thank you a lot!
Created attachment 174905 [details] A sample with LIST generating BLOB with zero bytes Hum. Maybe my issue is different after all. I couldn't repro with the attachment here. But this file gives me a "sluggish" experience (using my dbgutil build, I get tens of seconds until the query shows; trying to resize the column gives another delay; UI is unresponsive up to the point of requiring to kill it). Putting a breakpoint to OutputDevice::GetTextBreak shows that the rStr looks like > rStr = L"100х100х2,0;\0\0\0\0\0\0\0\0\0\0\0\0100х100х2,5;\0\0\0\0\0\0\0\0\0\0\0\0100х100х2,8;\0\0\0\0\0\0\0\0\0\0\0\0100х100х3,0;\0\0\0\0\0\0\0\0\0\0\0\0100х100х3,5;\0\0\0\0\0\0\0\0\0\0\0\0100х100х4,0;\0\0\0\0\0\0\0\0\0\0\0\0100х100х4,5;\0\0\0\0\0\0\0\0\0\0\0\0100...
(In reply to Mike Kaganski from comment #12) > I couldn't repro with the attachment here. I meant, I couldn't repro with attachment 145186 [details] from comment 1.
https://gerrit.libreoffice.org/c/core/+/121872
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/541ddf4580cac8c3f9590be26a487f5fc8e2553c tdf#120129: don't forget to update buffer size to actual length It will be available in 7.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-7-2": https://git.libreoffice.org/core/commit/c3cdc29900574fefe4dc8b90e2941f2d3371d89c tdf#120129: don't forget to update buffer size to actual length It will be available in 7.2.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-7-1": https://git.libreoffice.org/core/commit/e7e38c23d0a91e80535893ee88e3f0062b7d522c tdf#120129: don't forget to update buffer size to actual length It will be available in 7.1.7. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.