Teleportation for Your Found Sets

What is a good way to save a found set in your FileMaker application so that you can restore it?

This question came up this week on and a few different options were given, along the lines of our old blog post: using snapshot links or saving the primary keys of the found set to then do a Go To Related Records jump.

There is another option that we call TOG-hopping.


A TOG is a Table Occurrence Group: a cluster of connected TOs like the ones in the screenshot below. There are no relationships between TOGs which keeps the graph efficient.

Relationship graph that shows no relationship between the Table Occurence Groups


If you have a found set on a layout based on a TO that is part of one TOG and want to use that same found set in a layout based on a TO that is part of another TOG to use those existing relationships, two options come to mind:

  1. Duplicate those same relationships in the TOG where you are. This adds a lot of schema, and nobody likes to maintain duplicate sets of the same thing
  2. Add a relationship between your two TOGs, in essence making them one TOG. Now you are at risk of creating a spider in your graph and that may have a big performance impact.

There is a third option that allows you take the found set from one TO and recreate it in another TO *without* having to use an intermediate file like a snapshot link or having to collect all primary keys of your found set to use to rebuild the same found set elsewhere. You can just hop.

The same technique can be used to temporarily store a found set so that you can recall it at any time.


Consider this simple file that only has one table with fruits and which country they grow in:

Demo file only has one table with fruits and which country they grow in

And the graph has two TOs, with no relationship between them. Both these TOs are based on that fruits_country base table.

Table occurences are based on the fruits_country base table

The base table has 5,000 records, and when the file opens, both TOs have that original full 5,000 records found set.

On a layout based on the FRUIT table occurrence you search for all fruits that grow in Belgium, which gives you a found set of 32 records:

On a layout based on the Fruit table occurrence it shows 32 records when searching for all fruits that grown in Belgium

If you want to preserve that found set, you can use Go To Related Records from FRUIT to FRUITPARKING – even though these two TOs are not related. Yes, you can. Like this:

Use Go To Related Records from Fruit to Fruitparking too preserve the 32 records of fruit found set

Note that you pick the same TO as where you are: FRUIT but you pick a layout based on the other TO: FRUITPARKING.

When you run a script with this step in it, FRUITPARKING now also has that same found set of 32 records.

Found set with 32 records based on Fruit
Found set with Fruitparking showing same found set of 32 records

You can now manipulate the found set in FRUIT without affecting your parked / transported found set. If you want your original found set back, you can do the reverse:

Reverse the script to Get related record from Fruitparking to Fruit to do the reverse

And the found set from FRUITPARKING will be teleported back over to the FRUIT table occurrence.

This is a powerful feature that is not widely used. You can use to avoid proliferating duplicate relationships or avoiding complex graphs where everything is connected to everything else. Or use it for functionality where you want your users to go back to their previous found set.

Download the Demo

If you have any questions about this feature or need support in building out your Claris application, please contact our team.

10 thoughts on “Teleportation for Your Found Sets”

    1. Yes, it’s one of the easier ways to ‘park’ a found set. But it is hard then to restore that same found set in the window where you started from.

  1. Thank you for the solution,Wim.
    Already implemented.
    Question though: what if the TOGs are connected – will FM go hop directly, or will it try to go via the relationship graph – which might end up with a long query in progress?

    1. Hi Alex,
      I don’t have a ready answer for that. TOG hopping is a technique to avoid big spiders or break them up so I wouldn’t try and mix and match strategies and techniques. My assumption is that FM will try and follow the relational path if there is one but I would have to test it.
      Best regards,

  2. This never occurred to me, and I’m going to use it right away!

    And there is something else equally important that has never occurred to me: do lychees really grow in Belgium? In my view, greenhouses don’t count… No Life Support For Fruit!

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top