nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Subreports

prakash_p

Hi,

I have a master-detail report design which we have designed using List element. The question is, for each master record, BIRT is hitting database to get the detail records. Is it by design? if so, can someone explain why is it designed so? Dont mind if this is a baby question.

Regards...
Prakash...

Find more posts tagged with

Comments

mwilliams

Hi Prakash,

What version of BIRT are you using and how are you bringing in your sub report data? With the use of a dataSet parameter binding or are you filtering down the detail data to match the outer list data? Also, you are talking about just one report, correct? Like and embedded list/table within your master list? Let me know.

prakash_p

Michael,
I have single report, with a List and Table inside the List. We are not using Parameter binding, we are using Filtering feature. BTW, we are using BIRT 2.5.1 engine API to run our reports.

mwilliams

Prakash,

Can you attach your report design? I was under the impression that if you're just filtering that the database would not be hit again, all the work would be done within BIRT. This is why I asked about the dataSet parameter binding, because this would hit the database for just the small amount of data needed for the subreport, which is typically faster than letting BIRT filter all the data down each time.

prakash_p

Well, we also were under the same impression that the database querying should happen only once if we bind using Filtering. But, if you add a Table element and bind the Dataset (detail dataset) to the table and place it in the design before List element, the query is getting executed only once. Is this a bug?

mwilliams

Prakash,

What is the reason for using an outer list and an embedded table? Could you use a joint dataSet if needed to join the data and just use grouping to separate the data? Or if the data used in the outer list and the inner table are already in one dataSet, just use grouping to display the data how you'd like? Then, the database would only be hit once. Let me know if there's a reason for the subreport table.

prakash_p

We have tried with Join datasets too. There is a bug with joining datasets of type SPSelectDataSet. The second dataset values are never getting populated.

mwilliams

Prakash,

Is this a bug that you've found a bug report for or filed a bug for?

If you can't use 1 dataSet, I can see why you'd need a subreport. If it's hitting the database each time, the best bet might to be to set it up so that the subreport dataSet uses a dataSet parameter and you limit this pamameter using the dataSet parameter binding option on the binding tab of the inner table so that only the data for each section is brought in each time, rather than it possibly bringing in all the data each time and filtering out what you need.

johnw

Prakash,

Filters do not do any sort of filtering on the database side. Filters will retrieve data first, and filter in the BIRT engine at run time. If you are using a master/detail report, with a dataset bound to the inner table, BIRT will query the database for each row in the outer tables list. I was under the impression that there was a new feature (as of 2.3) that would cache the dataset results so it wouldnt make repeated calls for the same exact query, but I have never tested it. If you are using the API to run your report, there might be an option or property to set for this, but I am not sure off the top of my head.

I am assuming you are getting hit with some performance issues? If so, there are some things you can do with script to speed up these reports. Off the top of my head, my first recommendation is to drop you inner tables query into a hidden table at the top of your report, and through script, populate a collection with the results, probably a Map so you can key it. Then, in your master/detail section, just call off the map to populate your detail section.

Another alternative is a special ODA which can either cache those results someplace for you or will use an existing report document as a datasource, where the data has already been retrieved and filtered. We have done this in the past for clients who ran into similar issues.

John