>Well, not temporary per se, only assigned earlier than normal. Kenneth has to be doing it this way anyway to add child records to a parent table whose records aren't yet commited.

I really meant temporary, in the sense that they would get different keys when actually being saved, and these keys would only be there for linking purposes in the views. My assumption when I said it, was that he expected blank keys in all the new records, with 1 parent, 1 child and many grandchildren all related to one another, so they could all be assigned their foreign keys at once (while committing in the appropriate order) and be happy. I thought his problem was that, with the new child, suddenly you have two children with blank keys and don't know which one the grandchildren are related to.

But then Kenneth explained to me that he was already assigning the keys earlier than what you and I apparently consider normal (at commit time).

His problem (as you addressed elsewhere in your message) was requerying the grandchild table for a different child record. I told him "oh, OK, when your user tries to add another child, tell them they have to save current parent, child, and grandchildren first." I like your suggestion of a changing filter on the grandparent table, rather than a requery, better.

Interesting discussion though, for me, anyway. Thanks,