Using Queries as source for the Report Builder, the Report Wizard does accept all as being written. Running the Report Builder with output 'Text Document', a parameter is asked 1x, and the resultset is correct. Running the Report Builder with output 'Spreadsheet Document. a parameter is asked 2x, and the resultset is incorrect. (reported by bug: 136700) When using a Query to ask for the Surname of a person from a table like tPerson, the Query does accept: "tPerson"."Surname" LIKE '%' || :Surname || '%' to seek a resultset. This SQL statement is completely acceptable as correct by the Report Wizard, to create a Report. However, running the Report Builder for the Report, the Report Builder does not accept the same SQL. It appears the bug reported under 136700, is related to this issue. Apparently there is translation happening in Report Builder that causes this issue. Dream
@Dreamquartz : Please provide a test file with Query/Report and incdicate detailed steps so that we can try and reproduce. Please also indicate which OS and version you are using, and the Java version too.
Dear Dreamquartz, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Created attachment 170556 [details] Example of running the Report based on a Query The report is created directly from the Query qProject via the Report Builder Wizard. The resultset of the report is generated, based on the information required by the Query qProject. The resultset can only be created as a csv-file format if the information is entered twice. If the entry is based on ProjectNumber or ExternalProjectCode, the resultset shows a random result for ProjectNumber
[Automated Action] NeedInfo-To-Unconfirmed
Have tested this with the attachment. Have set as values for the parameter '123' - for Calc-file twice as reported. The content of both reports is the same. The numbers in Calc are formatted in a special way for numbers with 10 digits. ReportBuilder has problems to see a difference between the field name "ProjektNumber" and the parameter "ProjectNumber" - so the content of both documents is wrong here. I changed the name for the parameter a little bit and it works as expected.
Due to the fact the Report Builder allows a Query as input, there should NOT be an issue for parameters. It can not be so that the User must be made aware of the change in names for parameters. the Query !qProject runs and produces the correct resultset, but using the exact same Query in the Report Builder as input, provides an incorrect resultset. If there is an issue with Queries being processed by the Report Builder, the option of allowing a Query as a base to create a report should be NOT made available to the User. Dream
(In reply to Dreamquartz from comment #6) > If there is an issue with Queries being processed by the Report Builder, the > option of allowing a Query as a base to create a report should be NOT made > available to the User. Please open another bug for queries with parameter processed with the report builder. This is not the bug you have described here. When I read the title it is about different content in Writer or Calc. And this I can't confirm.
@Alex Maybe the title of the bug report is misleading, but that is what the bug is about. The resultset from the odt-format is different from the csv-format due to issue of parameters. The User is unable to simply take the Query as base for the Report Builder, to create a resultset that should be the same. The Report Builder is processing both variants for the resultset differently. If a 'issue' causing parameter is renamed by the User the Report Builder seems to be working according to the specs. However, in most cases the User is not the Designer, and therefore it cannot be expected from the User to modify the Query, or that the Designer has modify one Query, but not the other to get a resultset, just to 'please' the Report Builder. Hope this clarifies it.