Bret,

I was having about the same problems you described with code modeled from the same source. The tableupdate()s I added for the child seemed to be in conflict with the parent updates. I eventually got it to work, but I'm not sure why :)

I added a parent_table and a child_table to the one_to_many form class. When the user clicks the add button on the toolbar, it calls _screen.ActiveForm.AddNew() The form instance level calls the DODEFAULT() - AddNew() checks for the active control value and makes sure the control source is updated writebuffer(), I think, then gets the field state and processes them to see if there is a change in the records, offering a save if there are changes. (this is to the best of my recollection)

I compared the alias() to the parent_table and the child_table to see who was calling the addnew through the toolbar. If I was in the child I assumed the user wanted to add a grid (child) record to the existing parent. If in the parent, assumed I needed a new parent with a related but empty child.

Default values for newkey() in the DBC and a getparent() default for the foreign key in the child table

Then positioned in the parent, called the save(), which looped getnextmodified() to save the table, selected parent or child (whichever I was in when called)

All this was in the one_to_many class and generic, then surfacing to the form instance level the addnew() did whatever custom formatting of fields needed and set focus to the approppriate control or grid column desired as the starting point on the new record or row. As I recall, put the keys in to drop a part select box on the new child or drop the vendor select box on the new parent.

HTH,
Al Allison

PS: Nancy turned me on to views too :), thanks Nancy

>I guess I don't understand the intent of your question. Users want to be able to click their Add button, add a parent, select some related records, and click Save. These records are related many-many with the parent, so I make child records in the table that relates them.
>
>The most common example would be the creation of a new order and selection of products. One would not want to have to create an order with no items, click save, then click again to add order-items. But I would like my Add and Save code to be very generic, so I can use it in a variety of data entry forms.
>
>>Um, why aren't you just updating your views?
>>Worst case, you could trap the error and keep looping through, then go back through to get the children. < I'm not recommending this latter method, btw >
>>
>>>My Save button code loops through the open cursors in AUSED() and does a TableUpdate() on each. This code originally comes from the txtbtns class of WIZSTYLE.VCX. The problem is that when both a parent and a child record have been added, a "trigger failed" error can occur, probably because the child happens to get updated before the parent, and there is no corresponding parent record yet. I need a generic and flexible means for the framework code to determine which cursors should be updated first. I usually have parameterized views for the child grid and therefore no relation in the Form.DataEnvironment.