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.

>Hi Russell

>As the real SQL gurus advise, a primary key is supposed to be composed of multiple fields. I believe that is the index, of course, not that there be a single field that holds the concatenated value. A surrogate is supposed to be the exception.
>
>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.