After you add a record to the child, issuing a Child.Refresh will update the presentation. You don't need buttons to add/delete rows from a grid. There are deletion markers, record markers and AllowAdds and Deletion Events should you decide to do it through the Grid. Many in our business have coding standards that require interfaces with Grids to populate the grid (add/edit changes) through standard textbox controls. In other words, the grid is offered strictly as a preview, and populated through other form controls using replace or similar syntax.

Regarding "AfterRowColumnChange" (and similar events): Any movement on a grid triggers these events. Same row, but different column, or loss of focus. What I do in these cases is use the GRID's tag to hold a row (key) pointer-reference. In the "AfterRowColumnChange", if the current row reference fields match the string reference stashed in GRIDs tag, the ARCC is bypassed. If no match, the new pointer references are strung together and stashed in the TAG, and a "Change" process is instanced.

I know you had questions about table buffering. But I don't know how that works yet. It just seems that "replace" is noticable faster than an "update" call.
HTH TT

>Hi all,
>
>Does anyone have an example of a child grid update program. I',m still not sure where to start. Do I need buttons to add edit delete child records etc. When do I validate and do I need table buffering?
>Any help gratefully accepted..
>
>TIA
>Chris