Description: 1) The following query works fine, form editable: SELECT "Buecher".*, "Standorte"."Standort", "Buecher"."Position", "Standorte"."Standortid" FROM "Buecher" LEFT OUTER JOIN "Standorte" ON "Buecher"."StandortId" = "Standorte"."Standortid" ORDER BY "Standorte"."Standort" ASC, "Buecher"."Position" ASC 2) I added as with the sample-db conditions to the where-clause and introduced aliases. The form was no longer editable (but the form and the filter worked): SELECT "Bue".*, "Sto"."Standort", "Bue"."Position", "Sto"."Standortid" FROM "Buecher" "Bue" LEFT OUTER JOIN "Standorte" "Sto" ON "Bue"."StandortId" = "Sto"."Standortid" WHERE coalesce("Bue"."StandortId", 0) = (SELECT coalesce("F"."StandortId", "Bue"."StandortId") FROM "_Filter" "F" WHERE "F"."key" = TRUE) AND coalesce("Bue"."Titel", '') like (SELECT '%' || coalesce("F"."Titel", '') || '%' FROM "_Filter" "F" WHERE "F"."key" = TRUE) AND ((SELECT "F"."Autor" FROM "_Filter" "F" WHERE "F"."key" = TRUE) IS NULL OR ("Bue"."AutorId1" IN (SELECT "Aut"."AutorId" FROM "_Filter" "F" INNER JOIN "Autoren" "Aut" ON "Aut"."Autor" like '%' || "F"."Autor" || '%' WHERE "F"."key" = TRUE))) ORDER BY "Sto"."Standort" ASC, "Bue"."Position" ASC 3) I removed the conditions, but leaved the aliases. Form is not editable: SELECT "Bue".*, "Sto"."Standort", "Bue"."Position", "Sto"."Standortid" FROM "Buecher" "Bue" LEFT OUTER JOIN "Standorte" "Sto" ON "Bue"."StandortId" = "Sto"."Standortid" ORDER BY "Sto"."Standort" ASC, "Bue"."Position" ASC 4) I believed that the aliases could cause the problem, so I removed them, but used the condition. Form not editable: SELECT "Buecher".*, "Standorte"."Standort", "Buecher"."Position", "Standorte"."Standortid" FROM "Buecher" LEFT OUTER JOIN "Standorte" ON "Buecher"."StandortId" = "Standorte"."Standortid" WHERE coalesce("Buecher"."StandortId", 0) = (SELECT coalesce("_Filter"."StandortId", "Buecher"."StandortId") FROM "_Filter" WHERE "_Filter"."key" = TRUE) AND coalesce("Buecher"."Titel", '') like (SELECT '%' || coalesce("_Filter"."Titel", '') || '%' FROM "_Filter" WHERE "_Filter"."key" = TRUE) AND ((SELECT "_Filter"."Autor" FROM "_Filter" WHERE "_Filter"."key" = TRUE) IS NULL OR ("Buecher"."AutorId1" IN (SELECT "Autoren"."AutorId" FROM "_Filter" INNER JOIN "Autoren" ON "Autoren"."Autor" like '%' || "_Filter"."Autor" || '%' WHERE "_Filter"."key" = TRUE))) ORDER BY "Standorte"."Standort" ASC, "Buecher"."Position" ASC 5) I removed the "coalesce", since this is different with firebird. (This does not give the desired filtering, but just to try.) Form not editable: SELECT "Buecher".*, "Standorte"."Standort", "Buecher"."Position", "Standorte"."Standortid" FROM "Buecher" LEFT OUTER JOIN "Standorte" ON "Buecher"."StandortId" = "Standorte"."Standortid" WHERE "Buecher"."StandortId" = (SELECT "_Filter"."StandortId" FROM "_Filter" WHERE "_Filter"."key" = TRUE) AND "Buecher"."Titel" like (SELECT '%' || "_Filter"."Titel" || '%' FROM "_Filter" WHERE "_Filter"."key" = TRUE) AND ((SELECT "_Filter"."Autor" FROM "_Filter" WHERE "_Filter"."key" = TRUE) IS NULL OR ("Buecher"."AutorId1" IN (SELECT "Autoren"."AutorId" FROM "_Filter" INNER JOIN "Autoren" ON "Autoren"."Autor" like '%' || "_Filter"."Autor" || '%' WHERE "_Filter"."key" = TRUE))) ORDER BY "Standorte"."Standort" ASC, "Buecher"."Position" ASC Actual Results: I used a macro as in the sample-db to actualizize the records after entering filter values. The diplayed record is not editable, the combo-boxes are greyed out. Expected Results: The values should be editable. Reproducible: Always User Profile Reset: No Additional Info: Note: using aliases in some places but not in others produces an error message (missing column) when executing the query. Like SELECT "Buecher".*, "Standorte"."Standort", "Buecher"."Position", "Standorte"."Standortid" FROM "Buecher" "Bue" LEFT OUTER JOIN "Standorte" "Sto" ON "Buecher"."StandortId" = "Standorte"."Standortid" ORDER BY "Sto"."Standort" ASC, "Bue"."Position" ASC I believe this to be still correct sql. I tried with both the last official build an the last beta version. Version: 6.4.0.0.beta1 (x64) Build-ID: 4d7e5b0c40ed843384704eca3ce21981d4e98920 CPU-Threads: 4; BS: Windows 6.1 Service Pack 1 Build 7601; UI-Render: Standard; VCL: win; Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc: CL
@Helge : without a test ODB file that shows the reported buggy behaviour, this is going to be difficult to reproduce for QAers. Please provide a small sample ODB file that would allow us to reproduce the behaviour.
Created attachment 156338 [details] sample DB to demonstrate the bug
If you use the form "BuecherMitFilter" you will see fields not editable. You can edit the main form to get the data from some of the other queries with names starting with "BueFuerFormBue". (Different filters. Fields in form only editable with the query "BueFuerFormBue2noFilter". You might also execute the different queries directly to see the behavior. I assume that Base has a problem because the sql syntax of firebird is different from the old hsql.
@Helge : thanks for the sample DB. If I open the form Buecher, I can add new data and edit existing data via the form and this will be saved on validation. If I open the form BuechermitFilter, some of the fields appear to be editable, e.g. PreisDM, but nothing can be entered into them. I tried switching the query which forms the basis for the form, in Form Edit mode, then re-opening the form to see whether data entry was possible. I can confirming that the form becomes read only when any one of the filter queries is used as the datasource for the form. It seems that the queries including filters are all non-writable, i.e. they behave like Views (and views are not data-editable).
If I change the SQL mode in the queries, i.e. by deactivating the DirectSQL button, then in appearance I get an editable result set. This is shown by the Query result being displayed with a movable cursor within each record. However, if the Query contains an Alias, I can update a row via the GUI, but I get an error message if I just jump to a next row without clicking on the Save button first : firebird_sdbc error: *Dynamic SQL Error *SQL error code = -204 *Table unknown *Bue *At line 1, column 14 caused by 'isc_dsql_prepare' So here, the switch to a new record without explicitly saving the change beforehand triggers this error in which the Alias is not recognized. If you alter the Query "BueFuerFormBue6withoutAlias" to not execute in Direct SQL mode, then you can make changes to the result set via the Query UI, including jumping to a new record to effect the save of the change. Confirming. Not sure why switching off DirectSQL mode would make the query result set editable as opposed to non-editable. The error triggered by the keyboard navigation to another record I think has been reported by Robert in a different bug report.
Dear Helge, 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