| Category: | Feature request |
Priority: | Normal |
Status: | Acknowledged |
| Project: | Severity: | Minor |
Resolution: | Open |
|
| Component: | Reproducibility: | Always |
Assigned to: |
I received a report from someone else. I would like to take a look at it in iReport. But I cannot open it at all. I get the error message "net.sf.jasperreports.engine.JRException: No query executer factory class registered for obECS queries."
Clearly if I do not have the required Query Executer then I cannot run his report. But couldn't it be reasonable to still let me open the report? Maybe this could be a warning rather than an error.
My workaround is to edit the XML to change the query executer to something that I have. Then I can open the report. In this instance I am even able to run the report successfully because their customer query executer is very similar to our standard XPath query executer. In other cases perhaps it would be impossible to run the report. But it would still be useful to have the report open in Designer mode.
Sorry... I don't know the precise enhancement request. I'm not sure what a good solution is. But the use case I would like to solve is to be able to open a report in this circumstance.
4 Comments:
How do you feel about compiling the report?
Query executers register one or more built-in parameters in the report (which can be used in report expressions), so it wouldn't be possible to compile it when the QE is not available. Is that fine?
Regards,
Lucian
Yes, being unable to compile the report is reasonable.
I would like the user experience to be something like the following. (My focus is on the iReport user experience.)
1. I can open the report for which I do not have the query executer.
optional: Maybe I should see a warning. Maybe not.
2. I try to run the report or compile the report.
Result: I get a meaningful error message like "Unable to compile. Query Executer 'ABC' not found."
3. I am able to solve the problem myself now by choosing a different query executer in the report definition. The key difference from today's user experience is that I could do this from within the iReport designer GUI. I don't need to edit the .jrxml in a text editor.
Of course I could obtain the original query executer to solve the problem more completely.
Hi,
We think the solution is to register a query executer in iReport that would respond to all unrecognized query languages.
This fallback query executer would give the warnings you mentioned.
So I would rather move this to iReport. What do you think?
Thanks,
Teodor
For me that makes sense to make it an iReport issue.