Do you really need a found set? This sounds like a portal should work. This seems a little confusing with "my client" and "the client", but I think you want to look at a filtered portal instead of a found set via a find.
You should be able to add a portal from the client or contactss table and filter by 'ClientID = $$global_client_id'. This would also work with a self join. This will allow for editing as well it setup properly. This will also allow you to GoToRelatedRecord via the portal and that solves your link issue. Be careful about the target record table in a GTRR as sometimes you get the correct record and sometimes you get the first record in the filtered set. The FM documentation details this.
You can also filter a portal with ExecuteSQL if you think the relationship is complicated.
Why not simply use a Master-Detail approach on the Client layout itself? Add a non-filtered portal of related Contacts to display all contacts (and a few fields), and a filtered version of that portal for editing a selected contact (displaying all (pertinent) fields).
You can still let the user search for a contact name by performing the find in the related Contact::name field from the Client context.
If you have fm13 and up... also consider using a popover to show "editable" fields. That way you can seperate the display and the entering of data.
If you use a portal with a relationship to a global you can fill that global with the id's you need.
You can collect the id's in various ways (ExecuteSQL, a find or another relationship).
A "source" id can have multiple ids and FileMaker wil display the records associated with those keys in portal for example.
You can also get inspired by the Selector Connector model by Todd Geist and gang.
We don't know the client until we find the contact. The clients may be just
an informal group who always buy tickets together but it helps my client to
know that. We make up a name like Mary and Sue and friends but we never use
it with the client.
I could do this easily wig a union query but I don't think FM supports it.
I don't know how to set up the relationship table to use the filtered
query. I tried using a second TO of contacts joined on clientID. Didn't
work. Thinking of trying Find Matching Record to extend the found set.
Thanks for reply. It has given me ideas and I might be able to make the
filters portal work.
FileMaker does support UNION. https://fmhelp.filemaker.com/docs/13/en/fm13_sql_reference.pdf
For usability you really should consider a portal. Seems like all you need is a simple layout that uses a global field for the search and displays results in a portal and a popover to edit any data.
The Selector Connector was mentioned and it is very useful.
I'll give it a try tomorrow. Thanks for your help.
One way to do it is :
Create a global field in a table z_ClientIDs (maybe you have an interface table, or use the table the layout in question is based on)
Create a relationship from this global field z_ClientIDs to ClientID in your Client Table.
Create a portal with that relationship.
Then with an ExecuteSQL either with or without union fill the z_ClientIDs field as a list and all the clients you want will appear in the portal.
The z_ClientIDs field (being a global) is just a placeholder that FileMaker uses to fetch the related records. In other database systems you would the result of the query into an array and display that. Now you just fetch the keys and use a relationship to fetch the records. FileMaker supports using a list of source keys which makes this possible :-)
As is normal with FileMaker many different options, but none like other programming environments hihi :-)
Here a sample you can fiddle with...
ListofKeys.fmp12.zip 66.7 K
It looks as though you already have plenty of good ideas to try, but just an additional thought:
What about creating a self-relationship between contacts, where client id matches? You could use fields from that relationship (first, last, email) as your search fields, and pull up all contacts where one or more contacts for the same client have those attributes.
You'd want to take into account jumping to the particular contact once you've found the set (lots of methods for that), and you may need to account for contacts that don't have a client, if those exist.
This relationship could also be used to "easily jump to another contact within the same client".