I stand corrected. I tested it out and contrary to my prior statement you can have two (or more) relations into the same table. As you suggest, the currently selected parent table dictates which relation is active. Thanks.

>Well, I'll disagree with you too. :-)
>
>An example of a good application (IMO) of this concept would be a lookup table. Many tables can successfully be related to the lookup table but only one can be used at a time.
>
>>I disagree. There can only be one relation INTO a table. The next relation set into that table will replace the existing one. It only makes sense, as you point out. You can't move the record pointer of the table related into to different records at the same time.
>>That's my two cents.
>>
>>>Mark,
>>>There is nothing to prevent this but you should know you could have problems if you use Table1 and Table2 at the same time and try to retrieve data from Table3. A relation causes a corresponding SEEK to be performed on the child table whenever the record pointer is moved in the parent table. If you move the record pointer in table1 and then in table2, you probably won't be able to get the correct information for the table1 relation because the table3 record pointer will have moved in response to the second relation.
>>>
>>>You could use two SQL statements and process them separately or UNION them together and process them in one SCAN...ENDSCAN.
>>>
>>>HTH.
>>>
>>>>I have this question and perhaps it goes against some normalization rules
>>>>but is it possible to have two tables in relation with a single table
>>>>as in example:
>>>>table1 has
>>>>field1
>>>>field2
>>>>table2 has
>>>>field3
>>>>field4
>>>>
>>>>table3 (the child of the two above)
>>>>field1 (to be use on relation--table1)
>>>>field2 (to be use on relation--table2)
>>>>detailsfield1
>>>>detailsfield2
>>>>
>>>>etc
>>>>
>>>>or perhaps create a cursor to solve this problem
>>>>
>>>>tx
>>>>
>>>>marcos oliva