>>
>>No. The PI should be a separate tag by itself. There is no need to concatenate the value to other tags. In fact, I'd advise against this. It makes the other tags unnecessarily large and makes SQL SELECTs, SEEKs, etc more complicated.
>
>A typical problem would be: You got a customer file (keyed on cust act), you got a sale journal (key on cust act + inv numb). You getting ready to do an aging repor, but exclude customers that don't have invoices (and perhaps ,subsequently, ignore zero balances forward). How do you check if a customer has sales items?
>
>in xBase: && CusActInvoiceTag=CustAct(field)+Invoice Numb(fild)
>set exact off
>seek (MyCustomerAct,"SalesJournal","CusActInvoiceTag") && If seek TRUE, then customer has line item ** don't need a TAG strictly for customer act.
>
>or , SQL
>exists where SalesJounal.CustomerAcount=MyCustomerAct && Seperate firlds for Cust Act and Invoice
>
>or && Single field cocanked CustAct+Invoice
>exists where SalesJounal.CustomerAcount like(MyCustomerAct%) && One field, two keys
>
>Whats more complicated - a customer key (only tag) or cocanked fields (mutifield key)?

Don't use either. The PK should be system generated and seen only by the system. There is no reason for the user to see it. The user would see a customer number and fields that make up the concatenated key.