>>
>>With multiple indexes (or TAGs), each index (or Tag) would have a primary key, right? The primary key is the first "field" in the index key (example CUST+INVOICE, CUST is primary key). The same table, could have a different primary key for each index! Or, it could have the same primary key for a variety of secondary keys (or "sorts").
>
>
>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)?