Thanks Dustin



I really like the automatic child filtering ( with the caveat about collisions ) and I'm delighted that the one line of code in the parent's AfterAddNew solved the problems I was having.



I'm going to post the sample I created (and maybe at a couple of other parent/child things) so others can see the relative merits of some of these techniques.

Glad you guys got it worked out!

Yep, you have to be carefull on filters as most uses of a BO will go off of the CurrentView, and any changes that bring things into or out of the filter in the middle of a process could cause wonky results (to put it in technical terms.)

To answer Edhy's comment regarding collision detection, collision detection in this environment should still work fine, you would just be opening yourself up to more collisions the longer you went between pulling data from the database and saving the changes back. In other words, it would likely be faster from an access perspective to pull everything you may need back to the database and the save it when you are finished, but if this is a form they will be using for 10 or 20 minutes before hitting the "save" button, you'll want to account for that based on how your users are going to use the system (i.e. how likely it is that someone will edit the same record within that 10 or 20 minutes). 

Our medical application does something similar when you edit a patient record. Since patients are the central component of the system, there is quite a bit of data related to each patient's record.  To account for this, we've split up the editing functions into areas of common use ("Registration" for demographic info, "Ledger" for financial transactions, "Media" for media files, etc), and handle the saving slightly differently as appropriate for each area.

The "Registration" section, for example, pulls all registration information (from about 10 tables) related to the patient at once, and lets you edit any or all of it before hitting save. If you ever navigate off the "Patient Registration" page, however, we ask you to save your changes to persist them back to the database.  In the case of any data collisions, we just use the standard SF Data Collision form and methodolgy, we've just designed those areas of the system to minimize the collisions wherever possible.

You can use either approach, but it all depend on your application's business rule, ex: if you have multiple users working on the same time, then the filter approach could be problematic, since a user may be modifying a record that has been modified and I don't know how the SF concurrency checking will work in that case.

Edhy Rijo

The suggestion to search was a good one !

I think i may have this solved by putting the line

me.customersBO1.FilterChildrecords()

in the afteraddnew. 

Fixes the problem in adding on empty data tables and in clearing existing child data on adding a new with exisitng data

So far so good.  I'll try it in my big app and if it tests out I'll post the sample with comments for anybody else who might want to do this.

Thanks for that suggestion. I hadn't really used the autofilter before but I liked the idea of not making a trip to the server on every navigate. Perhaps I could still pull all the data and then set filters manually.



I any case this does confirm that the combination of autofilter and BBS is the problem .



Perhaps Trent can confirm?



I'll search the forum for references to this problem.



When get the sample working reliably I'll post it in the contributed samples so somebody else won't have to go through the day I've had

Charles,



Forgot to mention, remove all the code from the SalesBO1.ParentFormLoading().



I believe the problem was that the BO.AutoFilter option was filtering the data and causing some sort of thread invoke error. It is always better for you to handle your own filters.

Edhy Rijo

Do not use the BO.autofilter it is not safe, I don't remember details but search the forum for more info.



In the CustomerBO1.Navigated add the this code below Me.dgvSales.Refresh() and try.



Me.SalesBO1.FillByParentPrimaryKey(Me.CustomersBO1.pk_Customers)

Edhy Rijo

The probem seems to be that in AfterAddNew the bbsSales still has as _Businessobjectcurrentview the set of records based on the parent before the add.  Remember, the autofilter is on.  Perhaps the autofilter match current row doesn't play well with the BBS? 

If I add the line

me.SalesBO1.filter = "fk_Customers = -1"

it solves the problem for existing data but blows up when both tables are empty.

Edhy - here's the scripts for creating tables (sorry, thought the generated database script did that - should have checked it - I use DDT all the time so I'm script stupid )

Hi Charles,



Also in your scripts you forgot to include the table scripts for Customers and Sales.



I have not worked with data grid, I use the list view for this kind of data entry, but I will check it out to see if I can help dig out this problem.

Edhy Rijo

Second problem in this sample :

On new the grid doesn't clear until the parent is saved.  Calling dgvSales.refresh() or .refreshedit() in the Afteraddnew of the CustomersBO seems to have no effect, but as soon as new customer is saved the grid shows the empty child grid. 

Tried setting SalesBO1 to Include in Add bu that isn't the answer either.