| Summary: | Embedded Firebird ignores parameterized query input | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | Alex Thurgood <iplaw67> |
| Component: | Base | Assignee: | Eike Rathke <erack> |
| Status: | VERIFIED FIXED | ||
| Severity: | major | CC: | erack, raal, serval2412 |
| Priority: | high | Keywords: | bibisected, bisected, regression |
| Version: | 7.3.0.1 rc | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | target:7.4.0 target:7.3.1 target:7.3.0 | ||
| Crash report or crash signature: | Regression By: | ||
| Attachments: | Embedded Firebird test file | ||
|
Description
Alex Thurgood
2022-01-14 09:38:11 UTC
Created attachment 177541 [details]
Embedded Firebird test file
Also works correctly in Collabora Office Version: 21.06.9.1 Build ID: 0579e4dd91e7fd2e0574e3919b921e930642f8dd CPU threads: 8; OS: Mac OS X 12.1; UI render: default; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR Calc: threaded and LibreOffice Vanilla Version: 7.2.4.1 / LibreOffice Community Build ID: 27d75539669ac387bb498e35313b970b7fe9c4f9 CPU threads: 8; OS: Mac OS X 12.1; UI render: default; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR Calc: threaded On pc Debian x86-64 with master sources updated today, I could reproduce this. I could reproduce this on an hsqldb odb file. However, not sure my test was ok since typing this in Execute SQL statement SELECT * FROM "Timetable" WHERE "departure" > '08:00' failed with: Wrong data type: java.lang.IllegalArgumentException /home/julien/lo/libreoffice/connectivity/source/drivers/jdbc/Object.cxx:172 The goal was to find if it was specific to Firebird. This seems to have begun at the below commit. Adding Cc: to Eike Rathke ; Could you possibly take a look at this one? Thanks c8ece95d00e558f56c1d970745337bbf9254d2fc is the first bad commit commit c8ece95d00e558f56c1d970745337bbf9254d2fc Author: Jenkins Build User <tdf@pollux.tdf> Date: Thu Sep 23 20:33:51 2021 +0200 source f7d0c6b42a0a5ec98876006cd5048589219be741 https://git.libreoffice.org/core/+/f7d0c6b42a0a5ec98876006cd5048589219be741 Sort ZF_STANDARD_NEWEXTENDED_DATE_... into ZF_STANDARD_DATE category (In reply to raal from comment #5) > This seems to have begun at the below commit. > ... > https://git.libreoffice.org/core/+/f7d0c6b42a0a5ec98876006cd5048589219be741 > Sort ZF_STANDARD_NEWEXTENDED_DATE_... into ZF_STANDARD_DATE category I confirm, I don't reproduce the pb when reverting this commit locally. Let's increase a bit importance since: - it's a regression - it impacts all env It's possible not only Firebird (which is still experimental). If that commit affects time queries in Base then Base somewhere makes serious wrong assumptions about number formatter internal constants. HAHAHA https://opengrok.libreoffice.org/xref/core/connectivity/source/parse/sqlnode.cxx?r=16506994#220 https://opengrok.libreoffice.org/xref/core/connectivity/source/parse/sqlnode.cxx?r=16506994#232 https://opengrok.libreoffice.org/xref/core/connectivity/source/parse/sqlnode.cxx?r=16506994#245 That for this case 0.33333... (the 08:00 converted to double) results in being converted to date string "30 December 1899" which when converted to numeric is 0, hence all records match departure>0. (In reply to Eike Rathke from comment #9) > That for this case 0.33333... (the 08:00 converted to double) results in > being converted to date string "30 December 1899" which when converted to > numeric is 0, hence all records match departure>0. Thank you for the analysis and for the patch, just taking a look at git history, it was like this since initial import in 2000 (!!) Eike Rathke committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/0d6ab8d4ea7226db53d07dc158e176fe962fd8d9 Resolves: tdf#146757 Use correct format index keys instead of wrong hack It will be available in 7.4.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. (In reply to Julien Nabet from comment #10) > taking a look at git > history, it was like this since initial import in 2000 (!!) Yes, it was mere luck that the internal index keys had to be stable for the StarOffice binary file formats, a requirement that is gone for quite some years now.. Pending review https://gerrit.libreoffice.org/c/core/+/128527 for 7-3 https://gerrit.libreoffice.org/c/core/+/128528 for 7-3-0 After having updated my local repo (included Eike's patch) I confirm I don't reproduce the bug anymore. Thank you again Eike! :-) Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-7-3": https://git.libreoffice.org/core/commit/2492429199670e30d89a81e0e227ae894764baee Resolves: tdf#146757 Use correct format index keys instead of wrong hack It will be available in 7.3.1. 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. Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-7-3-0": https://git.libreoffice.org/core/commit/691f47959df0260ccee3a54e8d43df33e8aae9b5 Resolves: tdf#146757 Use correct format index keys instead of wrong hack 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. |