And my previous post covers that.  You can perform a query at the point of the child BO being referenced if you want to stream load instead of front load.

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.

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.

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

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?

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

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

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.

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

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