Report Best Way To Display Script Data

[jlandwerlen]

I have some test data that I was going to throw into a report. Currently the data is presented as a list of lists and is basically a name for the results and the results dataset.

[['Results Name #1', Dataset [3R ⅹ 3C]], ['Results Name #2', Dataset [13R ⅹ 3C]]]

All I really want is to display the name and the data underneath and repeat for as many times as the length of the list.

Is this doable? If so, how would the data keys look?

[pturmel]

You will want to reprocess into a properly nested structure to drive a table group. See this old topic for inspiration:

Report with Scripted Nested Data

The report datasource scripting examples explain how to access the nested data in another key for use constructing a custom dataset. What I don’t see is how to construct nested data that would be suitable for use with a child table in a table group. I have a parent dataset that I’m constructing via script due to annoying limitations of an ancient SQL Server 2000 instance. I need a subquery for each row that could be done with a normal query, but there’s no way to add a regular subquery to a s…

[jlandwerlen]

Thanks for the nudge

[jlandwerlen]

Got everything working except getting an error in the report, "unable to convert row x, column x to type class java.sql.Timestamp"

from com.inductiveautomation.ignition.common.util import DatasetBuilder
from java.lang import String, Integer, Long, Boolean, Float
from java.util import Date

b = DatasetBuilder.newBuilder().colNames("path", "value", "timestamp").colTypes(String, String, Date) 

All rows for column are java.util.Date. The only way I could get past the error was changing from Date to String. I guess it's no big deal, but for my benefit any idea what's going on here?

[pturmel]

Not sure. java.sql.Timestamp is a subclass of java.util.Date, so should be compatible. Share more data?

[pascal.fragnoud]

Oh. I spent some time trying to figure out exactly what data structure was expected by table groups… and ended up just nesting queries that shouldn’t be, just for the sake of getting what the table expects.
I’ll revisit that part of the report and see if it can be simplified with this.