Bug 51807 - No method to open a report from a macro with a filter
Summary: No method to open a report from a macro with a filter
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
3.4.5 release
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Database-Reports
  Show dependency treegraph
 
Reported: 2012-07-06 15:50 UTC by skiani
Modified: 2017-06-26 18:44 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description skiani 2012-07-06 15:50:40 UTC
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.
Comment 1 Robert Großkopf 2012-07-09 15:36:41 UTC
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"
Comment 2 skiani 2012-07-09 16:40:28 UTC
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?
Comment 3 Robert Großkopf 2012-07-11 06:20:21 UTC
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.
Comment 4 Lionel Elie Mamane 2012-07-12 09:49:52 UTC
(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.
Comment 5 Alex Thurgood 2015-01-03 17:38:00 UTC Comment hidden (no-value)