Hi Isabel.

Here's what I do. When the user hits Add, I store the current parent PK to a form or data management object property. Form is better if non-modal and multiple instances. I then INSERT the new record. After I append the new record to the parent, I requery the child view. It will be empty. Why? If referential integrity is being followed, there will be no blank ParentFK values. Solves that problem.

If the user cancels the addition, then I revert the changes, move the record pointer of the parent back to whatever PK value is stored in the custom form (or obhect) property I have alloted for that use and, again, requery the view.


>> 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.
>
>By this do you mean for retrieving a new key? If so, that part is already taken care of.
>
>> Now, as to tracking, I think the problem will resolve itself if you table buffer the children, use a parametized view for children,
>
>Although I have a VFP database, the client tier never interacts directly with it. The client tier asks the middleware for the data and has no knowledge of where it's coming from. Updates are sent to the middleware with instructions about the form in which the data is arriving and what data it applies to. I've got a firewall betwen the UI and the DB, and want to keep it that way. Also, I've left my DB in a pretty wide open state so that the model can accommodate a variety of business situations. I don't want my cascaded deletes, etc. built into it becuase the rules are in the middleware and are subject to change. Call me whacky, but I am intentionally keeping programmatic control over RI.
>
>> and do not allow a change of the parent record pointer if a child edit is occurring.
>
>In place already.
>
>I think maybe I'm not explaining myself well - won't be the first time. It's all the UI movement that creates the key mess.
>
>You click on a list and the pointer moves and you refresh the data and related, changed pointers. You click the Add button and add a blank record and need to also blank out the child data by way of removing the parent key, but still need to keep the original parent key around so you can refresh back to the correct record if the changes are abandoned. You add a new record, and have a set of nicely cleaned out keys, but then the user selects from a pick list of people and you have to update some of the keys so you can find appropriate addresses, and run the data retrieval code for getting those addresses, but once again you don't want that new key to stick around if there's a refresh. Etc., etc. Those are some of the cats I'm trying to herd.
>
>Thanks for the suggestions, which I'll hold on to. I appreciate the time.
>
>BTW, just the process of writing this out has given me more ideas on how to handle me key mess. I'll get there.
>
>Isabel