Your best bet would be to change the child business object to a shared variable so that all instances of your primary BO type have the same reference. Or, you could possibly add the code to populate the child into the Navigated() event of the business object and only bring in the records that match the current primary bo record, but that would greatly increase the number of database queries if you have a lot of parent bo records. Or, you could move the child business object outside of the parent business object and reference it there.
In the scenario described wouldn't you be bring a lot less data over the wire by pulling the lookup client info as part of a select statement that fills the primary cursor? ( and avoid a lot of the other hassles inherent in what is basically a related table model) If there are 10000 clients does the scenario described envision bringing 10000 records over the wire so the the 5 or 50 records in the primary dataset know the client description based on clientkey? It seems pulling a lot of records and then setting a filter based on the parentkey would be pretty intensive on the wire.
I guess what I'm asking is do issues of network traffic etc behave differently in the .NET/Strataframe world than what I'm used to in running VFP apps against SQL Server with remote views ( in Visual FoxExpress )
TIA
Charles