>>>If iKey1 is, say, a 5 digit field, you could have an index expression 100,000*iKey1 + iKey2. A tag like this could come in handy for ordering things if you are using the table itself, and not a view. But as many people here have told me, avoid compound primary keys and meaningful primary keys. At the very least, if you use compound keys, you will have to write your own RI code, because the RI code generated by vfp won't handle them. It is better to generate a surrogate key.
>>
>>I didn't see that it was for use as a candidate key. I totally agree with you that you should not use a composite key as primary or candidate key.
>
>I didn't say he shouldn't use it as a candidate index. If he needs to keep that combination of fields unique, and as long as they aren't used for a primary key, or updating, or a relation, what would be the problem? Is it a question of reverting correctly in a heavy multi-user environment?

What if you have a table of items that were included on an invoice where each record in the table has an invoice number and line-item id (not to be confused with the item's own unique item-number)? The invoice number combined with the line-item id are what make the record unique. For example:

    invoice#   item_id   item_no
      100          1     100101
      100          2     100103
      101          1     210106
      101          2     318256

This is common in point-of-sale applications. Invoice# and Item-id are typically integer fields and item_no may be character, numeric, or integer.