I doubt that the order of the values in the field have any affect on which record appears first.
But you could use a one row portal which filters for the last value in the list.
Getvalue (table::multiKey : value count ( table::multiKey ) ) = portalTable::key )
I'm sure the sort order (for the relationship or the portal) would be a factor. If there is no sort order, then creation order would be how it's sorted. But that's the sort, not necessary the 'arrangement' of the values in the multi-line key.
So the relationship between multi-line and portal matches any (in the multi-line key) and then sorts for the rows. If you ONLY show one related record it will still be that sort/creation order and the first one in that order is shown.
If you have a short on the relationship (as on the RG -graph), then C100 would be first and show in the first row of a portal or as single related field (not in a portal object).
If this field is not how you want to sort, you can have any other field in the same related table (I tend to have a serial # that is auto-enter, but can be changed to re-sort). The sort would still be on the relationship graph, but the first row would be based on that sort:
even though the storage in the key has a different arrangement, the 'rows' would sort on the first column (even if it is not displayed). And the 'first' would be: C145
Does that make sense?
There's not a lot to go on here, but the more I think about this, the more I wonder if replacing that multi-key field with a true Join table might make more sense.
For: this can only display one at any time
No, you can display all using calculation
List ( parent::field )
but the sort order is not same as key values, defined in relation (as already mentioned).
And key values can be duplicated but List() show one.
Well, yes, there is that, phil.
I try to use the multi-line key sparingly. But it's a cool feature if you consider all the variables with it!
If you *really* want to be sure it is showing the value from the first key, you could create a calc field that is GetValue ( MultiKeyField ; 1 ). Then set up a separate table occurrence and relationship based on this field. It's a little convoluted, but it should work.