Yep, report sharp shooter references the BO whenever it access a property, so rather than loading all child records up front, you can put a query in your reporting BO to pull only the currently relevant child records, effectively streaming the report. However, this doesn't really save you any time since it makes a bunch of small trips that add up to more load on the server as a single large query would.

We find that the bottleneck when it comes responsiveness on large reports is in the report rendering engine rather than data retrieval. We can print reports with hundreds of pages of data, and the query will typically spit the full result sets back in less than a second. On exteremely long reports (several hundred pages or more) with complex queries (a lot of joins and conditions), it might take 5-10 seconds to recieve the SQL results at the most. It is the nature of the beast in reporting, which is why you typically use criteria with logical boundries to avoid exteremly large record sets. Large record sets tend bloat your report, stretch out the time to generate that report, and make the final product more unweildy for the end user.

After reading Edhy and Ivan's reply, I realise I missed the point somewhat. I didn't realise you were pulling ALL child records, not just those applying to all included parents. Yes, by all means, attack that first to reduce the size of your record set. You should only be pulling back data that you are actually going to print. In our medical app, we go so far as to only pull back the columns that we know we are going to print, to reduce the footprint of the recordset coming back.

So ignore the above, and do what Edhy and Ivan said

Good point Dustin, I am not doing that yet, but will add it to my list to review, as well as convert those to use a Store Procedure instead.

Edhy Rijo

Hi, no i am not loading all child records. i am loading all child records from the parent records that are in the parentbo. in the application, a user can checkmark certain invoices. thoose checked invoices are loaded into the parentbo, and then the childbo loads all child records from thoose records in the parentbo.

hi ivan, if i use fillbyparentprimarykey as you suggest, will that automaticly update ? or would i have to put some code in that once the parentbo pk changes, it would call fillbyparentprimarykey on the childbo again to update ?

thanks

on a side note, does the bo expose all properties to the report, or only thoose where i add a ReflectionPropertyDescriptor for ?

Well, I think I haven't understood what you mean. When you det your BOs ready for printing, I assume the next step would be to run the Report. How would anything change at this time?

My report looks like this:

1stInvoiceTheUserChecked------------------------

INVOICE# and stuff...

INVOICE POSITION 1,

INVOICE POSITION 2...

2ndInvoiceTheUserChecked------------------------

INVOICE# and stuff...

INVOICE POSITION 1,

INVOICE POSITION 2,

INVOICE POSITION 3...

and so on.

So in my ParentBO i have all the invoices the user checked for appearance on the report. In the ChildBO -currently- i have all positions of thoose checked invoices.

Instead, what i would like is that when the repot engine renders the 2nd invoice, it would trigger something on the bo, so that the child bo only ever carries the thoose child records relative to the currently rendering invoice.

I got the impression that by using FillByParentPrimaryKey as you suggested instead of using FillMultipleDataTables and then set a filter, this would be possible. But for that to work, the childbo would need to update its records once the currently-being-rendered-invoice changes.

I hope that was not too terribly explained

Phillip,

You can do this and is just a design that you need to approach on your side.  I have mentioned out here on forum posts, especially when dealing with reporting type of scenarios, that you can really move time to the left if you will download and look at the StrataFlix sample.  It shows a great structure and format to creating reporting data sources.

Now in the StrataFlix sample, we populate all of the records for each BO at the same time and then filter out the child records through the exposed child BO property.  However, you can perform a query at this point instead of applying a filter.  So let's assume that you have something like this:

If you apply this logic using the layout and format of the StrataFlix reporting samples, then you should be right on track.

Hello Trent,

i did download and look at the strataflix sample. As from my posts above you may see, that i actually implemented it just like in the strataflix sample. the question in regards to fillbyparentprimarykey was in reply to a suggestion from Ivan as how to approach this with the childbo only having the records relevant to the current parentbo record that is being rendered at that time.