This technique may at least get you the portal filtering functionality that you are looking for.
As for how to handle de-duplication of records, that's going to be a little trickier starting from a portal filter of a Cartesian join.
Portal filters at the portal object level won't affect the relationship's found set, so since your portal is based on a Cartesian join, the actual portal found set will always be all Contact records.
You may have to change your portal relationship to something other than a Cartesian join to more easily evaluate duplicates or no-match.
Hope this helps.
Why do you want to do this in two stages? How many results are likely to turn up even for a common name? I take it yours is a rather small(ish) Contacts database, and we're not talking NSA.
You're querying a Contact database in which each record represents (hopefully) a unique person; what you mean by “duplicates” aren't really that, but multiple persons who share a common name.
IMO it makes more sense to display in the result portal those personal features (in a compacted format) that are necessary to identify the correct person among several same-named ones – and, hopefully, be able to spot and remove/consolidate any “real” duplicates. (Sex, DOB, and maybe a photo should be sufficient.)
Thanks Julio for your response, and your methodology was correct.
I just finished the solution. I used a custom function ExplodedPermutations(text) by Mike Hackett in a calculated field in the contacts table. I altered my relationship to match between my gsearch field in my student table and the newly created calculated field in the contacts table. I had to use an on modify script trigger to update the portal to perform the type ahead search. I then used a method shown here: FileMaker Portal Show Distinct Value Tutorial - The Scarpetta Group, Inc. to show only one of any duplicate names in the portal.
Thanks again Julio for your response!
Your correct, it was duplicate names, not duplicate records - my bad. I am not sure what the possibility is of having a matching name occur, but I was trying to plan for the eventuality should the situation arise. Since I wasn't sure of the likelihood and since I was limited on space, I opted to limit the data shown on each student to make the interface less cluttered. I felt a second step if the duplicate name situation did occur was a better approach to this particular situation. I do have a strategy in place to prevent duplicate records for the same contact which was a great suggestion.
You offered a workable solution, and some good points. Thanks for your response.