GTRR has a lot of uses. It can be used to look at the specific record
you are on, or the entire record set.
For example if you need to loop through the record set, you can GTRR to
a new window and a blank layout. then do the work, commit the data and
close the window. The user may not even know that a new window was opened.
In this case GTRR took the found set with it, so you just needed to
select the desired layout for the GTRR. You didn;t have to repeat the find.
True, you can get away with only using Go To Layout and Searching.
However, Go To Related Record(s) will be faster ( in most cases ) than Go To Layout and Search.
Also, there are a lot less script steps with Go To Related Record(s).
Bruce, but that's just the point. I never have to repeat the find. If on layout A I find George Unique, then go to layout B that is related and has contact details for people, it will only have details for George Unique when I get there, because I already found for George on A, and B is related to A. I can bounce back and forth between A & B and they will always only have George and his details. For that scenario it seems like GTL and GTRR are the same. No? Or they are the same but GTRR has other uses? Just trying to know why both commands exist. Must be something.
Eric, see my response to Bruce.
If on layout A I find George Unique, then go to layout B that is
related and has contact details for people, it will only have details
for George Unique when I get there, because I already found for George
on A, and B is related to A.
This is simply wrong. What you are describing is the function of GTRR.
Go to Layout has no regard for the record you leave nor for the record
your arrive on. In both cases it is the current record in the active
GTRR script serves you already with options as "open in new window" with parameters for windows-size and position and window-title. Options you would have to address with dedicated script-steps if using go-to-layout
Then in scripts I'll got to layout A, find a record, got to related layout B to do stuff to the related records. Layout B is already limited to just the one or more related records by its relationship to A.
That's where your basic misunderstanding lies. A layout by itself isn't filtered or constrained – it's a relationship that points to the TO of this layout that gives you a filter function from the context of a related TO. (Well, what Malcolm said. … ) A simple layout switch will just bring you to that layout/TO/window's current found set.
(And how would this work anyway? What if the layout's TO is related to multiple other TOs, e.g. a join table? Which parent's found set (or current record) would then determine the found set as a function of a relation?)
I rarely use GTRR. It has no dynamic parameters. You can't set the layout dynamically, it has to be hard coded. It buries it's logic in the step itself, making it hard to see what it's doing without heavy commenting. GTRR requires special attention to error handling (it will produce an error when matching the found set if the current record doesn't have a match even if the other records do) And, contrary to what others have said, it is not faster than doing a find. It actually uses FileMaker's native find under the hood somehow (you can see a find dialog on a slow GTRR).
The only time is when I have a found set and I want to go to related records, matching all. It's slightly more convenient to do GTRR rather than loop through the found set (scripted or a custom function) and collect the IDs, then create a find with those IDs.
Layout B is already limited to just the one or more related records by its relationship to A.
Not necessarily. For example, if you are on an Invoice and your script uses use Go To Layout to go to the Customer layout, the records there will be whatever was in the found set the last time you were on that layout. You would need to do a find to get to the Customer record for that invoice. GTRR will take you directly to the related Customer record for that invoice.
That is a surprise
- Try finding all records in B, then go from A to B again
- are there any script triggers on those layouts ?
- is it possible that both layouts use the same Table ?
> I'll got to layout A, find a record, got to related layout B to do stuff to the related records. Layout B is already limited to just the one or more related records by its relationship to A
I am with you David. Since the introduction of the Set Field By Name script step I have dropped GTRR too.
For scripted actions that have to modify related records, I don't find myself using either approach any more. Techniques like Selector-Connector and otherwise manipulating data through relationships spares the performance cost of switching layouts and enables transactional processing.
Another +1 on this approach. Finds are very fast and it can reduce the relationship graph clutter.
I was just being brief. I understand the base table, table instance, relationship, and layout scheme.