>>This sounds like a case where you find out how good your knowledge of MM is :)
>>
>>Commercial frameworks usually have very robust support for data updates, buffering, transactions, views, etc. If you do things "the MM way" usually there are no problems - that's the whole idea of the framework, details are taken care of for you, problems and gotchas are worked around in a best-practices manner.
>>
>>If you're doing your own data handling and it's not "the MM way", you need to make sure what you're doing is compatible with the environment that the MM framework is providing. Sometimes you need to do things like explicitly call framework methods like RequeryChildren(), or set a property like .ChildViewIsDirty so a parent object will automatically requery it for you. Knowing the right method to call or property to set is the "correct" way to handle this sort of thing in typical frameworks, rather than your own Requery() which as you point out is inelegant at best and may not work as expected in certain circumstances.
>>
>
>Basically, I'm not doing anything out of the MM way. I do have to make buffer dirty in the second table, otherwise it's not going to be saved.
>
>The only new thing I've added is a saving of Trans_Events in the biz object Save method. So, after I saved all the children, I'm instantiating a Trans_Events biz object on the fly, save it, then continue with the postsavehook of the biz object and commit the transaction. This should not interfere with the main saving process, but perhaps it does. When I step through the code in the Debugger, it seems to save everything correctly. I'll try tomorrow to disable saving of Trans_Events (it's setting one logical property to .f. in the PreSave hook) and see, how would it affect the saving process.
>
>However, I do need to save trans events. What could be my other alternatives? Calling a method of the form? But what if I changed several biz obj? I can, I guess, create some placeholder (array or object or whatever), put the information there and save everything at the end in Form's PostSaveHook method. This would mean, I have to re-design couple of things...
>
>
>>The other possibility is that you are doing things "the MM way", and you've encountered a framework bug. I've found a few framework bugs in my time, but in most cases it turned out to be something I'd done in a subclass of a framework class without understanding the full ramifications of the modifications I'd made.
>>
>
>We found few problems with MereMortals implementation of Save. MereMortals allows to save new empty record. For our purpose we don't want it, so we had to modify Save method slightly.
>
>But I don't remember finding framework bugs except for objects not properly releasing if called standalone (not from a form).
>
>
>>Unfortunately, all of these circumstances require you to have a deep understanding of the framework. I've found ultimately there is only so much you can understand when reading framework source code - a lot is quite abstract. To fix the tough problems I've had to resort to debugging, stepping through the code - including the framework code - so there's lots of lines of code to look at.
>>
>>So, those are your choices - do something like Requery() which works, but you don't really understand why - this is the equivalent of "hocus pocus". Or, bite the bullet and trace the code in the framework to really understand what's going on.
>
>1) I'll first try to see, if the view updates table as it should. I already tested the view alone and it seems to work fine, but I'll re-test.
>
>2) Then I disable saving Trans_Events to see, if it helps. If it does, we found a culprit.
>
> Then I would have to come up with a different way of saving the events...

I don't know MM at all, I was just making general comments - I can't help you with the details.