There does not appear to be anyway to open a report from a macro (e.g. button on a form) and apply a filter to that report. Similar to how you can open a form from a macro using a filter. Something like this should work: oReport = ThisDatabaseDocument.ReportDocuments.getByName("MyReport") oReport.open oReport.filter="( ""tbProjects"".""ProjID"" = " & ProjectID & " )" oReport.ApplyFilter=True oReport.Reload() The only solutions I have been able to find require either generating a temporary table on the fly and opening a report against that. This solution only works in a single user environment. The other solution is to open the report in design mode modify the filter then generated a report. This also is problematic in that user must have write access to the LO file, also an non-starter in multi-user environment. Ideally we can open reports just like forms with externally applied filter.
You could write your filter-values in a separate little table. This values could be read with a query. Only SQL-function you need is IFNULL(...) - then the filter works, when there is an input in the filter-table, or the whole data were shown. I changed the Status to "New", because I can confirm the behaviour you have described. Changed also the Platform to "All"
I think separate table is a possibility, would have to write out everything for the report then delete the records after the report is created. How would I make that work in a multi-user environment?
In a multi-user environment the input in the little filter-table must be blocked during the time the query needs it. Could be a way to create a view. The database knows, who long the view works. When the view is working the input in the filter-field could be blocked through the user. I have not tested it - don't work with Base in a multi-user environment. Have set the Importance to "enhancement", because the only way to connect with a macro to the report is to open the report - nothing else.
(In reply to comment #2) > I think separate table is a possibility, would have to write out everything for > the report then delete the records after the report is created. How would I > make that work in a multi-user environment? Most database systems have a notion of temporary table that are specific to one connection / session. But that is still an ugly *work-around*, I'd prefer we fixed this bug. The difficulty lies in the fact that a report opened in normal (non-design) mode is not a report anymore, but a writer document. So indeed, manipulating it as a report does not work. How about just letting people edit reports in a read-only file, but just not let them save the file? That would solve this problem cleanly, and probably others.
Adding self to CC if not already on
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.