After testing both cases, you're right. It's best to fetch just the record I need on demand. This project will use your ES, so I always have to think about database being remote.



Thanks for confirmation!

..ßen

Definitely.  We've used both in the past, but I think we generally end up going with the "pull the children for one parent at a time" option.  Mainly because in our software, you're generally only working with one parent at a time, except for cases like reporting or inquiry, etc (there's no need to manage 2 patients at the same time on the same form...).

Thanks Ben; So, I have the choice going either direction depending on the recordset size!

..ßen

I think it mostly depends upon the size of your recordset and your user's perceived latency.  If you can load up all of the records up front, the response will be faster for the duration of the maintenance of the data.  However, if load up the records as needed, you won't have the front-end hit.  In our experience, filling the child records as needed is faster (if you have an index on the foreign key of the child table, that is ).  But either way would work the exact same, it's just personal preference.

Thanks Trent; I'm truly enjoying the power that SF offers, as I'm getting into more features.





This point cleared up my confusion. Let me ask you this, as I looked at the samples I see you mostly approach getting the children in a different way (rather using this property), which once the user lands on a specific parent record, then you fill the child only for that parent.



As a rule of thumb, which is a preferred way:



1) Retrieving children per parent:

(pro) This option fetches small number of records from the server.

(Con) in 3-tier too many round trips to the server



2) Retrieving all children:

(Pro) A lot less round trips to the server

(con) Heavy up front load, and possibly could use up too much client's memory.



Any suggestion or guidelines is appreciated!



Thanks!

..ßen

You will set this on the parent BO.

It means that only child records that belong to the current record on the parent BO will be filtered.  So if the parent BO has a PK value of 3, let's say, then any child records whose foreign key matches a value of 3 will be fitlered. 

The ChildAutoFilter property only filters the records in the child BO that have already been retrieved from the server.  So if you call the FillByParentPrimaryKey method then there is no reason to even set the ChildAutoFilterOption property at this point.

Hi;



A few questions regarding this property in BO:

a) Should this property be set on the parentBO or childBO or both? (the help doesn't specify which one)



b) By setting this property to "MatchCurrentRow", Does this mean, as the "CurrentRowIndex" in the parent BO changes, SF will automatically fills the childBO by parent's primary key?



c) What if I need to call ChildBO FillByParentPrimaryKey method myslef, Do I still need to set this property?



Thank you in advance!

..ßen