Description: Opening the "2 Amps to Volts-High by Series" By main "Queries", right click and choose "Edit" In view, changed 134 to '134' Message: Warning The entered criterion cannot be compared with this field. Remove 134 from Series and hit enter. <Edit><Run Query> results in all records Add 134 to Series and hit enter. <Edit><Run Query> results in just 134 Series records. Query Design <Save > Double left click on query name "2 Amps to Volts-High by Series" Message: The data content could not be loaded. Error code: 1 <More> firebird_sdbc error: *Dynamic SQL Error *SQL error code = -104 *Invalid usage of boolean expression caused by 'isc_dsql_prepare' By main "Queries", right click and choose "Edit in SQL view..." Remove AND "Amps"."Series" = '134' <Edit><Run Query> results in all records Add AND "Amps"."Series" = '134' <Edit><Run Query> results in just 134 Series records. Remove Add AND "Amps"."Series" = '134' and add Add AND "Amps"."Series" = 134 <Edit><Run Query> results in just 134 Series records. Saved the query in multiple states When ever I save the Query and double left click from main Query window on "2 Amps to Volts-High by Series" Results in error message: <More> firebird_sdbc error: *Dynamic SQL Error *SQL error code = -104 *Invalid usage of boolean expression caused by 'isc_dsql_prepare' In effect, in either edit mode it works correctly. The saved query always fails. However, when query is "Save As" it works correctly with newly named query. Steps to Reproduce: There seems to be something wrong in the saved query, which isn't shown while editing the query. For other users: 1. I have tested to execute the query. 2. Execution fails. 3. I opened the query in design-view. 4. I executed the query. 5. Execution works. ... This is the problem, what nobody could understand ... 6. I changed something in the query (removed "Equipment"."Series" = 134 ) and saved the query. 7. Closed the design-view. 8. Execution fails. ... Then I opened the query, added the removed part again, saved ... All the same. ...But when I open the query and save the query with a new name the query will be saved with this new name and could be executed. So I created, for example "12 Amps to Volts-High by Series" and it works. Actual Results: ...But when I open the query and save the query with a new name the query will be saved with this new name and could be executed. So I created, for example "12 Amps to Volts-High by Series" and it works. Expected Results: Query "Saved" should work. Reproducible: Always User Profile Reset: No Additional Info: This was issue was originally raised on users@global.libreoffice.org The information supplied is based on questions and answers there.
Would it be possible you attach an example file so it can be reproduced easily and quickly?
@Paul : ideally, we would need a test file in order to try and repeat, otherwise we will be kind of guessing as to the structure, data content and query definitions
Created attachment 148491 [details] Database prior to migration Also used to create bug 122812
Could confirm the buggy behaviour. Had tested the database, changed the original query in SQL-mode - nothing works. Then I only opened the query to edit and saved it with a new name. The new query - with the same SQL-code - could be execoted now directly from the Query-pane. Tested with LO 6.1.4.2 on OpenSUSE 15
Yes, I confirm that "Saved As" works correctly while "Save" does not. Have you also noticed that the Query works in both "Edit" and "Edit in SQL View...", but not when Query is "Saved" in either? I apologize for the random quality, but I have slowly been learning about Base over the years which has left some queries/forms/reports outdated.
On pc Debian x86-64 with master sources updated some days ago, I get a crash during Firebird conversion.
After having fixed the crash, I could reproduce this.
Lionel: it seems to me we've already encountered this kind of problem, a different interpretation of the request depending the location we call it. Any thoughts?
Dear Paul Mirowsky, 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