>*snip*
>>My question is this: Could any problems arise from creating a persistent relationship between two indexes which are not identical?? I realize that VFP's automatic referential integrity will not work in this situation, but that really isn't a problem. I will programmatically handle the referential integrity issues. There may have been a better way to do this, but this was the easiest method for me, considering the complexity of the data and user needs. This is a very complex application, with many sources of data being displayed at once.
>>
>>The thing that is bothering me is that I have created a relationship between indexes which are not identical. Is there any possibility that this could cause the records to not appear, or the wrong records to appear in any particular circumstance?? Apparently, VFP is matching the patient table index to only the social_security portion of the procedure table's index expression. The grid seems to be using the entire index to sort the records correctly. It appears to be working correctly, but I'm worried that I did something wrong that may come back to haunt me.
>
>Dave,
>You will be okay with this configuration because of what relations actually do and how VFP treats seek expressions.
>
>When a relation is set up, a seek is performed in the child table whenever the record pointer moves in the parent table. The seek finds corresponding records because VFP compares only up to the length of the source expression. Because your target expression consists of SSN and then date, the seek on the SSN succeeds.

The inverse relationship fails, though - drive something off the child with a relation to the parent could fail if the child key is used to maintain the relation to the parent, like when you wanted to generate a list of procedures performed in one day which required fields in the parent record.