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

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.

Ok, I have a little more information I'm not sure what to make out of.  When it raises the ListChanged event in the BusinessBindingSource code like this:

Protected Overridable Sub OnListChanged(ByVal e As ListChangedEventArgs)
  RaiseEvent ListChanged(Me, e)
End Sub

I set a break at the raiseevent and step, but before it comes back from the event it hits the break in the Primary BO's Navigating event and my Clients.Count is back to zero.  Before the ListChanged event is raised the Clients.Count is correct.  Is this a DevExpress thing or is this an issue with how the BindingSource is interacting with it or do you have any idea what's going on here?

 

Ok, one thing I think I did leave out was that the primary BO is used in a BusinessBindingSource to display in a DevExpress TreeList.  I mention that now because the Clients.Count seems to change somewhere in the following code.  Is there anything in here that could be causing something to fire off somewhere else I'm not aware of??

Private Sub BusinessObject_CurrentDataTableRefilled()

  '-- Remove the handler on the old current view
  RemoveHandler _BusinessObject_CurrentView.ListChanged, AddressOf      BusinessObject_CurrentView_ListChanged

  '-- Save a reference to the new view
  Me._BusinessObject_CurrentView = Me._BusinessObject.CurrentView

  '-- Add the handler to the new view
  AddHandler Me._BusinessObject_CurrentView.ListChanged, AddressOf   BusinessObject_CurrentView_ListChanged

  '-- Raise the list changed event
  Me.OnListChanged(New ListChangedEventArgs(ListChangedType.Reset, -1))
End Sub

 

 

If you have the SF source code built in debug, you can put a breakpoint in the BusinessLayer.vb file somewhere around 2109 or 2110 which should be the ChangeCurrentDataTable() method.  It should get hit when the table is refilled or cleared (when a Clear() is called).  You might give that a try...

I actually have breaks in Clients_CurrentDataTableRefilled, Navigating, and Navigated.  None of these are hit in between the primary BO events I talked about.  They are hit before that and the values are correct at that point, but between the CurrentDataTableRefilled and Navigating of the primary BO the row count value changes.

Hrm... you could try putting a handler on the CurrentDataTableRefilled event of the child business object and put a break point in it.  Then look at the CallStack window and see what called the refill further up the line.

The CurrentDataTable.Rows.Count corresponds to Clients.Count....both are correct when in the PrimaryBO_CurrentDataTableRefilled handler, but when it gets to the PrimaryBO_Navigating event handler, the counts are zero and there is not a Filter set, it is "". 

I looked at the BusinessLayer code here and there wasn't much going on between these events that I could see.  I also don't handle any events for Clients and it is a private object so it's not messed with anywhere else either.  I will continue looking, but I can't see anywhere I am filtering the rows or refilling the table. 

You might check the CurrentDataTable.Rows.Count and Filter properties to make sure that the records are not being filtered out.  Since the business object navigates off of the CurrentView, it might be that the records are still there, but just not visible for some reason.

Actually, by the time it gets into the Navigating event Clients.Count is already zero.  It is 353 in the PrimaryBO_CurrentDataTableRefilled handler, but then when it goes to the PrimaryBO_Navigating event where I would expect to change where Clients is pointing, the count is back to zero.  I'm just not sure what's happening here...any other ideas anyone?