Created attachment 133880 [details] database to demonstrate the bug To demonstrate this bug open the attached HSQLDB data base and Edit Query1. Double click on each of the three links, and confirm join directions and note the comments saying which table gets 'ALL' and which table gets 'only'. Initially the links are setup so: left of the link 'ALL' items are selected, and right of the link 'only' matching items are selected, or specifically: The Table3-Table2 link: Right join Table2 | Table3 Contains ALL records from table 'Table3' but only records from table 'Table2' where the values in the related fields are matching. The Table2-Table1 link: Left join Tabel2 | Table1 Contains ALL records from table 'Table2' but only records from table 'Table1' where the values in the related fields are matching. The Table3-Table4 link: Left join Table3 | Table4 Contains ALL records from table 'Table3' but only records from table 'Table4' where the values in the related fields are matching." Now click the Switch Design View On/Off to show SQL view. Copy and save the SQL for later analysis. Then click Switch Design View On/Off a 2nd time to come back to the GUI design to see that it's changed one of the JOINs. Again double click on the links to show the join conditions. Expected results: the links join conditions should be exactly the same as before, or as noted above. Buggy results: Although the join direction specification ('LEFT' or 'RIGHT') don't seem to change, RANDOMLY the comments below do change. Here is one such recorded incorrect Type and associated comment: The Table3-Table2 links reads: Right join (Note this is now Right when it was Left before!) Table3 | Table2 (Note this is swapped from before!) Contains ALL records from table 'Table3' but only records from table 'Table2' where the values in the related fields are matching. The Table2-Table1 links reads: Left join Tabel1 | Table2 (Note this and below are swapped from before!) Contains ALL records from table 'Table1' but only records from table 'Table2' where the values in the related fields are matching. ^^^ This is now wrong The Table3-Table4 links reads: Left join Table3 | Table4 Contains ALL records from table 'Table3' but only records from table 'Table4' where the values in the related fields are matching." !! I have also seen the Table3-Table4 link do the same thing, but not at the same time as the above result. I can't tell why it happens sometimes one way, and another time the other way. Now take a look at the SQL that you saved above: SELECT "Table3".*, "Table2"."Text2", "Table1"."Text1" FROM { oj "Table2" RIGHT OUTER JOIN "Table3" ON "Table2"."Table2 ID" = "Table3"."Table2 ID" LEFT OUTER JOIN "Table4" ON "Table3"."Table4 ID" = "Table4"."Table4 ID" LEFT OUTER JOIN "Table1" ON "Table2"."Table1 ID" = "Table1"."Table1 ID" } or pretty printed this becomes: ...FROM { oj "Table2" RIGHT OUTER JOIN "Table3" ON "Table2"."Table2 ID" = "Table3"."Table2 ID" LEFT OUTER JOIN "Table4" ON "Table3"."Table4 ID" = "Table4"."Table4 ID" LEFT OUTER JOIN "Table1" ON "Table2"."Table1 ID" = "Table1"."Table1 ID" } This is correct. Simplified this is: ((Table3 -> Table2) -> Table4) -> Table1 BUT click Switch Design View On/Off twice more and then look at the SQL. I'm now getting this: ...FROM { oj "Table2" RIGHT OUTER JOIN "Table3" ON "Table2"."Table2 ID" = "Table3"."Table2 ID" RIGHT OUTER JOIN "Table4" ON "Table4"."Table4 ID" = "Table3"."Table4 ID" LEFT OUTER JOIN "Table1" ON "Table2"."Table1 ID" = "Table1"."Table1 ID" } This is wrong. Simplified this is: (Table 4 -> (Table3 -> Table2)) -> Table1 The table 4 join is wrong. So only by clicking the Switch Design View On/Off button a few times, SQL is changed and does not agree with the original GUI design.
Until this is resolved, and in addition to this being resolved, and because this has created bugs in SQL, I think it would be a good idea to draw the links between data sources (tables or queries) in the GUI as an arrow rather than a simple line, so you can immediately see which way the join points. A -> B == A LEFT JOIN B or B RIGHT JOIN A A <- B == A RIGHT JOIN B or B LEFT JOIN A
Created attachment 133932 [details] Exampledatabase with dates - open the query for editing and switch designmode on and off (more than 2 times) I could confirm the buggy behavior. But it isn't easy to reproduce without data. So I have added Data and relationship to the first attachment. So you could see the changing when switching on and of query-design-mode run the query every time. Could reproduce the bug with every LO- version here - also LO 3.6.7.2. Could be it is introduced by OOo. My system: OpenSUSE 64bit rpm Linux.
Because you can't edit any query in GUI mode, even if you don't change a single thing in the design, without it very often and quietly messing up your joins, resulting in silent data integrity consequences, I am requesting that this please be upgraded to MAJOR. For example, you can't even open a query, change nothing at all, then save the design, without fear of it having messes up your joins. So afterwards when you run the query, like in a report, the data is selected wrong and some records are left out, and you might not even notice it for some time!!! The painful workaround for now: Every single time you edit a query you have to manually check each and every join to make sure that it hasn't gotten messed up. For queries with one join this isn't too much of an issue, but for queries with 5 or 10 joins, this is a pain in the neck to have to do each time you try to edit the query. Other observations: * I also noticed that some times a Right or Left join gets changed to an inner join. * I have noticed that this bug occurs when the SQL is interpreted so it can be graphically visualized, either: a) when the query is opened to be edited graphically, or b) when the query is in SQL edit mode, and then switched to be edited graphically. * Fortunately the bug is not when the query is saved, but only when it is opened for edit in GUI mode. So at least there is a way to inspect and fix the design each time before it is saved.
I agree the pb is important since: - it concerns all env - it changes data without warning Lionel: I tried to investigate dbaccess/source/ui/querydesign/QueryDesignView.cxx (eg GetNextJoin, BuildJoin) dbaccess/source/ui/querydesign/JoinTableView.cxx but am a bit lost. If you have any idea where to dig...
Isn't this a duplicate of bug 83121 ?
Dear Howard Johnson, 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 http://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
Bug still exists in LO 6.2.4.2 on OpenSUSE 15 64bit rpm Linux.
(In reply to Robert Großkopf from comment #7) > Bug still exists in LO 6.2.4.2 on OpenSUSE 15 64bit rpm Linux. .... And still exists in LO 6.2.7.1 on OpenSUSE 15.1 LEAP 64bit rpm Linux I use a databaseconnection with postgres
Dear Howard Johnson, 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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Bug still the same. Switching designmode sometimes change the table names in outer joins. Version: 24.8.3.1 (X86_64) / LibreOffice Community Build ID: 65412f067af443213e726c93f137ccc85c9a1e06 CPU threads: 6; OS: Linux 6.4; UI render: default; VCL: kf5 (cairo+xcb) Locale: de-DE (de_DE.UTF-8); UI: de-DE Calc: threaded