I agree with David F.! Under FoxPro for DOS and Windows I also used compound keys. That was the way I was taught and it made since to me. But, like David mention, I now use a control table and increment a integer counter field using a stored procedure in the "Default Value" property of the primary key. Integers take less space to store and indexes run quicker off of an integer than a compound key (I don't remember who or what issues, but somebody wrote a whole series of articles in the FoxPro Advisor about this within the last six months.

These integers also, without a doubt, uniquely identifies a particular record in the table when set up as the primary key. This will help in the future if you use local views. This single primary key also eleviates a lot of headaches if, and when, you move your application to client-server.

>Luco
>
>Since VFP added the integer field type, I strongly recommend that you stop using compound keys for relations. Just use uniquely internally generated keys in sequence to provide the links between tables. With parameterized views retrieving child records can be done in any order you choose.
>
>>I'm used to work with compound keys. For me that means that the primary key of a table consists of two fields which make it unique.
>>
>>When I set relations, I can make a relation using only the half of the key(1 field) which I relate to another table.
>>
>>How can you implement this in Vfp ?