Syncing a supporting BO with the primary BO


Author
Message
StrataFrame Team
S
StrataFrame Developer (4.6K reputation)StrataFrame Developer (4.6K reputation)StrataFrame Developer (4.6K reputation)StrataFrame Developer (4.6K reputation)StrataFrame Developer (4.6K reputation)StrataFrame Developer (4.6K reputation)StrataFrame Developer (4.6K reputation)StrataFrame Developer (4.6K reputation)StrataFrame Developer (4.6K reputation)
Group: StrataFrame Developers
Posts: 3K, Visits: 2.5K
Aha, using a BBS does make a difference.  Basically, the business object tries to act like a single record, but it has several records inside of it.  So, to make it work with the BBS (which expects a list of objects and a different reference for each object within the list, not just the same object over and over again), we have to create a new instance of the BO, share it's data table with the BO you selected as the BusinessObject for the BBS & set it to the right record, and return that new instance of the BO for each index of an item in the list.  So, the problem is that your root business object that contains the populated child reference is not the actual business object being used by the BBS.  That business object is a different instance of the same business object type and shares its CurrentDataTable with the root business object (they have the same reference), and it has its own internal child business object that isn't populated.

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.

Charles R Hankey
Charles R Hankey
Advanced StrataFrame User (950 reputation)Advanced StrataFrame User (950 reputation)Advanced StrataFrame User (950 reputation)Advanced StrataFrame User (950 reputation)Advanced StrataFrame User (950 reputation)Advanced StrataFrame User (950 reputation)Advanced StrataFrame User (950 reputation)Advanced StrataFrame User (950 reputation)Advanced StrataFrame User (950 reputation)
Group: Forum Members
Posts: 524, Visits: 30K
Pardon me for jumping in on this but as a complete .net newbie threads like this raise some 'best practices' questions that occur to me frequently in my transition from a world of VFP remote views.

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

GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...




Similar Topics

Reading This Topic

Login

Explore
Messages
Mentions
Search