The data retrieval is done with a sproc that will be created by the DDT package.

For anybody that does not have the DDT I am also attaching the scripts to create Gridtest.mdf and the two sprocs

TIA

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.

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 )

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.

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.