Hi Isabel,

OK, so then you are using surrogate keys. Good deal. In that case, and in conjunction with the way you are allowing edits, you might want to consider a GenKey property in a data service tier and to keep the physical structure of your keys all the same.

Now, as to tracking, I think the problem will resolve itself if you table buffer the children, use a parametized view for children, and do not allow a change of the parent record pointer if a child edit is occurring.

Let's say that all tables have a primary key called PK and children have a column called FKParent which is the foreign key to parent. If you add a new parent you can:

View = SELECT * FROM sourcetable WHERE sourcetable.fkparent = ?parent.pk

cPK=oDataServices.GenKey()
INSERT INTO parent (pk) VALUES (cPK)

Adding a new child:

cPK=oDataServices.GenKey()
INSERT INTO vueChild (pk,fkparent) VALUES (cPK,parent.pk)

Simple? Yup. Now you can save or discard the whole mess after the edit with just two TABLEUPDATE()s. Oh, and for DELETE, you can either use built-in RI or create another data service method to manage it.

>>There is no one good answer to this scenario. Are the primary keys data-bearing or surrogate? Meaning, are they keys that the user sees such as ID numbers or are they internal to the application and the user never sees them?
>
>The user never sees the keys.
>
>> Another factor which comes in to play is the back-end database. Is this native VFP or SQL Server or Oracle or ???.
>
>The back end is VFP.
>
>> Finally, what is your UI paradigm for editing data with parent-child and parent-child-child relationships? This matters. If the user can simultaneously add/edit parents and children and (god-forbid) grandchildren this sets up a whole new set of problems.
>
>The deepest the user can add/delete is the child level. For example, phone numbers and addresses for a person being edited. In all cases where you can add/delete children, the child adds/deletes are accumulated, with deletes being visibly marked, and are saved when the parent data is saved. In this specific case, I save the parent data data first, pass the new parent id along to the children, and then save the children.
>
>Here is a specific parent-child-child scenario. I have a family (a real family - people) that has relationships with "other important people" who are members of families of their own. My parent is a list of families. Child level one is a list, for the selected family, of these "other important people". Child level two is a record for the selected "other important person". The single record is a physical implementation of what is logically more width to the selected child level 1 record. I have to separate the child one and two levels, because I have to hold on to both the family id for the parent list and the family id for the "other important person"'s own family. Below this I also have the phone/address stuff for the "other important person". In this case the editing actually happens down in the child levels only. Are you having fun yet?
>
>In any event, what the user sees is not particularly complicated, but the underylying functionality is a mess of keys. I have already made logical maps of my specific scenarios, and am slogging through the fine points of what keys have to be in what states when. I'll end up with finite, specific templates of how things work.
>
>What I need to develop is a rational way of managing these keys within this set of defined complex situations. I'm not as concerned her with "What do I do with my family id?" as I am with "What approach can I take?" and "Does this management really belong in the form?"
>
>BTW, this is basically a single user system where "last-in-wins" saving is sufficient.
>
>Thanks again!