>>I'm new to this so this is an elementary question. In setting up persistent relationships, I have 1 table with a primary key that is one field. That is the parent table. In the child table, does the index that's related to this parent have to be on that field only or can I have it on 2 fields with the first one being the one that matches the parent table? For example - the parent table has a primary key on code; the child table has an index on code & subcode. Do I need to add an index to the child table that is code only?
>>
>>Thanks.
>
>This is very similar to setting a normal relation between tables. The only way the relation will work is if the value of the index record in the parent is equal to the value in the child table. If you can do that with an index on multiple fields, then you can set the relation. Whatever value you have in the parent has to be of the same data type, width and value in the child table to get a match.

Thanks for the reply. I understand the relation part. I'm used to issuing a statement in DOS when using the child table - SET RELATION TO CODE INTO (parent file name). However, in DOS, I didn't need to have an index in the child table that matched the parent index. The field type, width and value had to match. Now, in VFP I need an index that matches the parent index. So my question is - if my index in the parent table is code and my index in the child table is code + subcode will the persistent relationship work? I get a trigger failure when adding a record to the child table. Do I need to add an index to the child table that is code?