You've checked the relationships and scripts, but not the data itself.
I'd imagine that somehow the data is messed up so you're not getting the data matched correctly through the relationship, or at least not how you're expecting it to work.
Drop some portals on either side of the relationship and look at what related records show up, look for and correct any issues before retesting.
Hi Mike. Thanks for your response.
I apologise for making a false statement in my original post. The problem only applies to one pair of tables and not 3 pairs (I have 3 sets of criteria, via 3 scripts, for selecting the child found set).
If I limit the child found set to any set of multiple records, the parent still comes up with the same 819 records when I apply the GTRR script.
If I limit the child found set to a single record, the parent still comes up with the same 819 records when I apply the GTRR script.
If I change the GTRR script to “Match the current record only”, the parent found set shows one record but an unrelated one.
If I apply GTRR to other child/parent pairs in the Dec file, it works fine.
I still think my answer applies, and something is wrong with your data, or how you're using the script step.
What kind of keys are you using, UUID or serial? your errant results could be from text stored in number fields (or vice versa).
Can you post a sample of your file or even some screenshots of the relationship graph?
I have tried another approach. I have written a single step script to execute the GTRR and do a FIND on the child set then execute the GTRR. The result is the same so it isn’t the script that’s at fault. However:-
There is a second TO of the parent that relates to the child through a 3rd table. If I delete the relationship between the 1st parent TO and the 3rd table (to isolate the 2nd TO) and run the GTRR, the result is:-
FM opens the layout for the 3rd table and halts, showing an error message that says “This operation could not be completed because the target is not part of a related table”. Why is it opening the layout for the 3rd table? Could this be related to my problem?
However, when I repeat this using the Jul file, the GTRR works fine.
The data relationship has definitely not changed since July and is created through a portal in the first place. I have checked some samples and they look fine.
Might be a glitch with the indexes. Try turning off indexing on the key fields, saving the database, and let FileMaker rebuild the indexes.
Mike x 2
I’ve sussed it out and it’s all my fault.
I have a 2nd, unrelated script that is triggered when the child layout closes. The GTRR closes the child layout and triggers this 2nd script which then opens the 3rd layout. When this script completes, the parent layout is opened but the relationship to the child found set has already been lost. When I stop the 2nd script from being triggered, all is good!!
Thanks for your ideas and for being sounding boards. It helped.