If you use drill down reports on a chart, the drilldown column index for the required parameter should be between 1-3. This was also the case with version 2. Documentation can be found at https://sourceforge.net/p/art/wiki/Drill%20Down%20Reports/ (at the very end of the page). Documentation for version 2 was similar. For version 2, if you specified anything outside this 1-3 range, it defaulted to drilling down on the series name, rather than throwing an error. Version 3 generally throws more errors rather than defaulting to values that the administrators may not be aware of and may not have intended.
For the errors, let's start with the last one, where java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 3. For this report, we need to go through a similar process as before. Select the Configure | Reports menu, find the report and open the Drilldowns menu from the Actions column. I assume you'll only have one drilldown report here since the stack trace indicates that this is a timeseries based chart - so either a time series chart or a date series chart. Once you identify the drilldown report, go again to the Configure | Reports menu and this time find the drilldown report you identified. For this report, select the Parameters menu from the Action column. Note the IDs of the parameters listed. For each of those parameters, select the Configure | Parameters menu, find the appropriate parameter ID, Edit and confirm the drilldown column index, looking for one that is greater than 3. Let's resolve this one first, then we'll come to the other one.
well, i'm bad. I went back and looked again at the parms. And it was the same issue as before. The drilldown parm was set to 4 in both cases. When i changed them to 3 they worked. Is this something I'm going to have to change when we go live to v3?
Thanks,
Ray
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes. Like I mentioned, the documentation specified 1-3. It is better to throw errors with invalid values rather than accept invalid values and default to some value which may not be documented.
What you can do is run the following query on your current (version 2) database to change all drilldown column values for charts to 3 where this value is > 3. Then you won't have issues after the upgrade.
update art_query_fields aqf
inner join art_queries aq
on aqf.QUERY_ID=aq.QUERY_ID
set aqf.drilldown_column=3
where aqf.drilldown_column>3
and aq.QUERY_TYPE<0
I just tested JasperReports: Template Query and i can't execute report on beta version. The same report can be executed on version 2.5.4.
I tested it more and I created empty report (in Jaspersoft Studio) with several static fields without DB connection and every time i got some kind of error in version 3.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK. So I believe this problem doesn't affect all reports?
What you can do is start from a simple report and then we can see if we can find out where the problem is. Are you able to do this - start with a simple query and then add report elements of the current report until you get the problem.
Hi Timothy :)
First I would like to congratulate the release of the new version. ART 3.0 looks very nice and the new features are awesome.
Unfortunately I have a problem with my first report in this version from SQL Server database.
I created a connection as a Datasource using com.microsoft.sqlserver.jdbc.SQLServerDriver. Everything works fine, the application see database and connection test is successfull. Next I added a simple tabular report. This is SQL source:
SELECT *
FROM [dbo].[R_KontrahenciInfo]
[R_KontrahenciInfo] is a view - in Management Studio execution takes only one second.
The problem occurs on XLSX output format.
When Im trying to execute this report from ART 2.53 everything works good, it takes max 10 seconds. (see 1.JPG). But the same operation in ART 3.0 lasts "forever" - more than 300 seconds (see 2.JPG). I see that in the meantime the system creates a file in \WEB-INF\work\export\reports but most of the time it only weighs 4 kb and not growing (file is empty inside, there's not even header). Both versions of ART stand on the same machine, on the same Tomcat 7.0, but have different app names. The other format type like Browser (DataTable) works fine, but this report is to big to show in the browser.
Do you have any idea what could cause this problem?
I'm not sure if I was clear in the earlier post. Just to say that this thread should not be used anymore to post issues. Now that version 3 is officially out, new issues should be created for each issue, for easier follow up.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK. Let's address one issue at a time.
If you use drill down reports on a chart, the drilldown column index for the required parameter should be between 1-3. This was also the case with version 2. Documentation can be found at https://sourceforge.net/p/art/wiki/Drill%20Down%20Reports/ (at the very end of the page). Documentation for version 2 was similar. For version 2, if you specified anything outside this 1-3 range, it defaulted to drilling down on the series name, rather than throwing an error. Version 3 generally throws more errors rather than defaulting to values that the administrators may not be aware of and may not have intended.
For the errors, let's start with the last one, where
java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 3. For this report, we need to go through a similar process as before. Select the Configure | Reports menu, find the report and open the Drilldowns menu from the Actions column. I assume you'll only have one drilldown report here since the stack trace indicates that this is a timeseries based chart - so either a time series chart or a date series chart. Once you identify the drilldown report, go again to the Configure | Reports menu and this time find the drilldown report you identified. For this report, select the Parameters menu from the Action column. Note the IDs of the parameters listed. For each of those parameters, select the Configure | Parameters menu, find the appropriate parameter ID, Edit and confirm the drilldown column index, looking for one that is greater than 3. Let's resolve this one first, then we'll come to the other one.well, i'm bad. I went back and looked again at the parms. And it was the same issue as before. The drilldown parm was set to 4 in both cases. When i changed them to 3 they worked. Is this something I'm going to have to change when we go live to v3?
Thanks,
Ray
Yes. Like I mentioned, the documentation specified 1-3. It is better to throw errors with invalid values rather than accept invalid values and default to some value which may not be documented.
What you can do is run the following query on your current (version 2) database to change all drilldown column values for charts to 3 where this value is > 3. Then you won't have issues after the upgrade.
update art_query_fields aqf inner join art_queries aq on aqf.QUERY_ID=aq.QUERY_ID set aqf.drilldown_column=3 where aqf.drilldown_column>3 and aq.QUERY_TYPE<0It is possible to schedule Dashboards? I need to send email with several different objects (tables, charts etc.) in one message by Job.
No. This is not currently possible. It has been requested several times before so may be something that can be looked at.
I just tested JasperReports: Template Query and i can't execute report on beta version. The same report can be executed on version 2.5.4.
I tested it more and I created empty report (in Jaspersoft Studio) with several static fields without DB connection and every time i got some kind of error in version 3.
Could you post the error details for the report that runs in 2.5.4 but doesn't run in version 3.
Simple blank report
Is there any error indicated in the logs.
No, log doesn't contain any errors about this problem.
Last edit: Paweł Osuch 2017-04-03
OK. So I believe this problem doesn't affect all reports?
What you can do is start from a simple report and then we can see if we can find out where the problem is. Are you able to do this - start with a simple query and then add report elements of the current report until you get the problem.
Just uploaded 3.0-rc1. Hopefully this will be the last "test" release before a final 3.0 release in about a month's time.
Link to rc-1 files - https://sourceforge.net/projects/art/files/art/3.0-rc1/
Just uploaded 3.0-rc2. Hopefully next will be the final release.
Link to rc2 files - https://sourceforge.net/projects/art/files/art/3.0-rc2/
Just uploaded rc3. https://sourceforge.net/projects/art/files/art/3.0-rc3/
Just uploaded rc4. https://sourceforge.net/projects/art/files/art/3.0-rc4/
Just uploaded 3.0-rc5. https://sourceforge.net/projects/art/files/art/3.0-rc5/. Hopefully this will be the last release candidate.
Hi Timothy :)
First I would like to congratulate the release of the new version. ART 3.0 looks very nice and the new features are awesome.
Unfortunately I have a problem with my first report in this version from SQL Server database.
I created a connection as a Datasource using com.microsoft.sqlserver.jdbc.SQLServerDriver. Everything works fine, the application see database and connection test is successfull. Next I added a simple tabular report. This is SQL source:
[R_KontrahenciInfo] is a view - in Management Studio execution takes only one second.
The problem occurs on XLSX output format.
When Im trying to execute this report from ART 2.53 everything works good, it takes max 10 seconds. (see 1.JPG). But the same operation in ART 3.0 lasts "forever" - more than 300 seconds (see 2.JPG). I see that in the meantime the system creates a file in \WEB-INF\work\export\reports but most of the time it only weighs 4 kb and not growing (file is empty inside, there's not even header). Both versions of ART stand on the same machine, on the same Tomcat 7.0, but have different app names. The other format type like Browser (DataTable) works fine, but this report is to big to show in the browser.
Do you have any idea what could cause this problem?
BTW I will create PL translation in time soon.
Last edit: Paweł Osuch 2017-10-11
Hi Pawel,
Could you please create a new post and copy this issue there. It will be easier that way going forward.
I'm not sure if I was clear in the earlier post. Just to say that this thread should not be used anymore to post issues. Now that version 3 is officially out, new issues should be created for each issue, for easier follow up.