I'm sure you understand the concept better than I, and either I have some misconceptions(I'm sure of this), or I'm stating things poorly.
The view I was describing consisted of two tables. The main table having a primary key IrKey which needs to be included in the view definition and set as the key field. In order to have this key updated in the child table it would also need to be included in the view definition - hence two entries in the view. From what I'm seeing/gathering, if I don't include the child table's IrKey in the view definition, I would have to wait until after the table was updated and do the work at that point.
The posting from Craig essentially confirmed what I was seeing - e.g, the key wouldn't be created until after the view's TableUpdate. I either need to wait to finish the "job" until after the TableUpdate was completed, or get the predicted key value and update as you suggested. Both approaches worked, but trying to find a solution where I'd been looking wouldn't have - I had hoped an append into the view would immediately create append(s) in the underlying table(s). While the append(s) do happen, they don't occur when I had hoped.
The GUID you mention wouldn't resolve that part of the issue, since I would still need to wait until the Save() for the child record to be created, and at that point I could find the assinged IrKey in the Parent table. I'm not sure what you mean by GUID, but assume it's similar to the approach used for assigning registry keys. If so, wouldn't the size of the key need to be fairly large to guarantee uniqueness(e.g, larger than I(4))?

I appreciate both your input and Craig's.
Thanks again,
Michael