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