Repeating fields aren't dangerous, just awkward and inefficient when compared to newer alternatives for most cases where you might use one. Even today, there are cases where a repeating field can be useful, but you need to understand their limitations and the advantages of possible alternatives before you can make an informed choice to use them.
If I use a traditional relationship then I have to have three separate portals but if I create a repeating field that includes all the child keys from the three different fields then it will display the 1 job in each of those personnel’s portals (I have checked this and it works a treat)
That is one of the cases where a repeating field is still a valid option, but a single text field with multiple match values listed and separated by returns can serve the same purpose and not be limited to the number of repetitions you define for the match field.
I'm not sure your tables are really set up to support what you want to do. Check me on this:
A given job record can link multiple personnel and a given personnel record can link to multiple jobs?
If so, that's a many to many relationship and best implemented with a join table between jobs and personnel.
Many to many relationships can be set up in FileMaker with either a repeating field (not a good idea) or a return separated list of values (better), but these options are not as flexible as using that join table.
Thanks for that Obi-Wan (the alex guinniess version),
I had tried a return separated field but it hadn't worked and I thought repeating fields were the only way. This was because I used a calculating fields and it turns out that child keys need to be indexed.
So the basic answer that I was looking for is that you can't use a calculated field to create a relationship with another table. Repeating field or not (I feel so dumb)
Return deliniated fields are much better (but of course you knew that) and I've done a lot of other cute stuff with it today.
But you can use a calculated field, but it must be an indexed field. A calculation field that pulls data from other tables--not what you need here cannot be stored and thus has no index. Such a field can even be used in a relationship if it is used on the "one" side of a one to many relationship.