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 community.claris.com 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.
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:
- 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
- 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:
And the graph has two TOs, with no relationship between them. Both these TOs are based on that 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:
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:
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.
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:
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.