Hi Russell

>I'd like to see the reasoning behind a multifield PK. I've always preferred a surrogate for the PK. If I understood what you meant in your parent-child-grandchild relationship example, then if the user scrolls through invoice header records for a parent, why can't you just query for the line items that belong to that invoice. I've certainly done things like that before. Quite fast with VFP, as I'm sure you know.

I'm glad you asked! You'd have to force the user to save all changes, before you could requery either the child or grandchild cursors.

With the FKs available throughout the hierarchy - you gain the ability to SET FILTER or SET KEY on the children/grand children as the user navigates without saving anything.

Admittedly this isn't the best example, because you'd seldom add a customer record and then add invoices and line items per invoice without saving, but with this approach you could do it!

>>I've been using surrogate/factless/meaningless keys for a long long time. I like the construction consistency, but I have recently seen what might be a flaw in the surrogate key for everything idea.
>>
>>If I have Companies, Invoices, and LineItems:
>>
>>

company
>>cmp_pk    cmp_name    cmp_cityfk
>>1         comp 1      1
>>2         comp 2      2

>>
>>

invhead
>>inv_pk    inv_no    inv_cmpfk
>>1         001       1
>>2         002       2

>>
>>

invline
>>lin_pk    lin_desc         lin_invfk
>>1         jam              1
>>2         peanut butter    2

>>
>>I cannot do a single form parent-child-grandchild relation because invline does not have the cmp_pk in it. It would be required for me to query all line items from invline and filter them as the user navigated among invhead records for a particular company.