>>>>>>>I am curious. How do most of you do 1-many-many form? Use parameterized view on the child table and grandchild table and set filter to the grandchild while the child is moving? Or Use parameterized view on the child table and grandchild table and set relation between the two? Or use normal view on both and relate the 3 generations together?
>>>>>>>
>>>>>>>Is there a best solution?
>>>>>>
>>>>>>I don't know if it is the best solution, but I use parameterized views for the child and grandchild. I don't set a relation. The parameter for the child is the parentkey, and the parameter for the grandchild is its parentkey. I also have code for my grid that makes the selected record highlighted, even when the grid does not have focus.
>>>>>
>>>>>Sorry, are you saying grandchild's parameter is the child's primary key? That will mean you need to commit your changes each time you change your child record, right?
>>>>
>>>>I should mention that my grandchild table isn't exactly a grandchild. It's more like a younger brother. I have a table of "things", related many-to-many with a table of "documents". In my "document" form, there is a grid for the view "thingdocs", which lists the things for a single document. Its parameter is document.dockey. The "things" table has another child called "authorizations". My "document" form has another grid for the view "thingdocauth" which has the authorizations for the currently selected thing in the thing grid of the document form. Its parameter is thingdocs.dockey. In this form, "authorizations" is acting like a grandchild. But I don't edit authorizations in this form. For that, I go to a simple parent-child form which has thing fields on the form and authorizations in the grid.
>>>>
>>>>My Save button does TABLEUPDATE on each open cursor.
>>>
>>>Your grandchild's (authorization) child order is actually the grandparent's (document) key, right? I guess that is the only way to have grandchild as parameterized view.
>>
>>My authorization records are ORDER BY a different field. The parameterized view only selects records whose thingdocauth.dockey = ?thingdocs.dockey. It doesn't need to be ORDER BY dockey, because all selected records have the same dockey.
>>
>>I forgot to mention that I REQUERY('thingdocauth') in the thingdoc grid.AfterRowColChange. Both views get REQUERYed in refresh.
>
>I am sorry. I got confuse and wrote childorder instead of parameter. What I wanted to ask was: your parameter for the child and grandchild views are actually the same, right? Because thingdocs.dockey = document.dockey, therefore it is as good as saying your grandchild is referring to the grandparent for the parameter. That is why you mention your grandchild is more like a brother.
>
>If the view is an actual grandchild, I can't think of anyway I can use parameterized views for both and yet keep them in buffer.

I'm sorry, I made a mistake. The parameter for "thingdocauth" is not thingdocs.dockey, it is thingdocs.thingkey. The grid for thingdocauth is showing the authorizations for the currently selected thing in the thingdocs grid. Those are the things for the currently selected document in the form.

When I get something working, I sometimes forget how it works. Then I get tongue-tied when I try to explain. I hope no-one snips this thread. My reply will look like gibberish if no-one can see what a "thingdocauth" is :)

I am no expert on buffering, but I think you're right. It is probably best not to allow users to edit parent, child, and grandchild all in one form. When the user goes to different rows in the child grid, the grandchild grid must either be REQUERYed or allowed to become out of date. Either keep the grandchild grid readonly, or make the grandchild view non-updateable, or something. Make another parent-child form for the children-grandchildren. I should go back and check my form to make sure that it is secure.