Hi John,

That is so true. I stumbled across it about a month ago (I think I had seen Jim Booth mention it in a post). It solved some major problems I was having, and once I realized how it worked everything became so simple.

I had a contract form with a pageframe. Each page has a read-only grid showing child records (I use buffered views) of the contract table (services, employ rates, consultant charges, etc.). Each grid would have a Add / Edit / Delete button cluster that calls a form to edit each child record in that view individually. In order to allow the called from to work in the dirty view I just set it to the default data session. Works perfectly. I ended up making the button cluster a class with a ViewToEdit property.

The only tricky thing I did, and I would like your opinion on this, was dealing with the user canceling from the child form. IAW the user clicks the edit button, a new form is called (with controls bound to the dirty view's fields in the init), makes some changes (the view is now reflects those changes), and clicks cancel (I now need to change the view back to it's previous state). The only thing I could think of was to wrap the whole DO FORM in a transaction. As the transaction is only affecting the local view I don't think I will be a problem. Any comments or concerns about the transaction part?

>Hi Jim,
>
>That "trick" of using the default datasession in a child form to share a parents DS, with the parent using a private datasession is one that a lot of people are simply unaware of. It's not really well documented. Perhaps it should be the subject of an article here or in one of the mags.
>
>>