>Maybe I need to explain further.
>
>table1.Field1 & table1.Field2 together make up my primary key for that table.
>
>str(field1)+'.'+str(field2) is my primary key.
>
>
>I have another table that has that key value stored in a field .
>table2.field1=(str(table1.field1))+'.'+(str(table1.field1))
>
>I need to create a relation. The only relation it will allow me to create in the DE is by making table2 the parent. This will not work for me, I need table1 to be the parent table. It wont let me create that relation. Because there is not field, just an index in that table.
>
>So I thought If I could create an additional field that was calculated in table1, I could use it for the parent relation.
>
>Maybe there is another solution??

Well, you could consider using sequential numbers for your primary keys. This would allow you (in most cases) to have a single field (4 bytes) as both the primary key and the foreign key. This would save space, and simplify relations. There are also some disadvantages (see my article on primary keys, in the UT Magazine), but I still prefer to use these "auto-incremented" fields as primary keys.

If you prefer to stay with your current primary keys, I am not sure about relations - I never had to create this sort of relation. Well, perhaps you should do this programmatically, through the SET RELATION command. The relation is from any expression, to a table (active index is used), so you should have no problems here.

Hilmar.