>>>Thank you Hilmar for this improvment ! I suppose that BINTOC will not preserve the order for sorting (at least, the doc doesn't say that it preserves the order) - but that is probably unimportant in my case.
>
>>I think it will, because of the binary representation. I am not sure about negative numbers.
>
>OK, to be tested then !
>
>>But you must be careful to use only "Machine" for the collation sequence. "Machine" is already the default, but you may have changed this.
>
>>bintoc() will accept the entire range of a 4 byte integer, i.e., from minus to plus 2 thousand million, approximately.
>
>Thank you for these details. This solution seems to be as close as one can get to a real composite key.

On the other hand, relationships between tables will be a lot simpler if you store the PK in a single field. For example, let's say you want to have a "composite" key, one part a number of the branch office, another a sequential number, generated by a function, SerialNumber(table_name).

In an invoice table, the primary key might be a field of type C(6), with the following default value:

bintoc(BranchNumber, 2) + bintoc(SerialNumber("invoice"))

Then, you have a key made up of the two parts, but in a single field.

BTW, some programmers prefer to use a GUID instead, but those use 16 bytes.