# R.I.P - GTRR

**URL:** <https://the.fmsoup.org/t/r-i-p-gtrr/355>\
**Category:** Heads-Up!\
**Tags:** scripting, slowing\
**Created:** [October 2, 2019, 5:26pm UTC](https://the.fmsoup.org/t/r-i-p-gtrr/355 "2019-10-02T17:26:12Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![AndyHibbs](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/andyhibbs/32/3089_2.png) [@AndyHibbs](https://the.fmsoup.org/u/AndyHibbs)\
**Post date:** [October 2, 2019, 5:26pm UTC](https://the.fmsoup.org/t/r-i-p-gtrr/355/1 "2019-10-02T17:26:12Z")

</div>

We’ve mentioned this since the release of FMS v16, but it looks as if we’re going to have to reengineer many of our systems that use the Go to Related Records script step.

I’ve just had to replace a single line of GTRR on a button with a script that comprises of about 22 lines once error capture, comments, etc. are included.

GTRR was such a staple element of our development since FileMaker became a relational database, but over the last 3 years, it is going to have to be retired, as (in Windows) we’re constantly getting ‘Not Responding’ appearing when using it, whereas entering find mode, go to layout, set field, perform find works instantly.

I have no idea what they’ve done to the database engine, but in today’s case the relationship was one hop away without any further links and had 2 conditions in the field match, hardly complex.

I’ve previously reported upgrading a client from v14 to v17 who had a brand new well specified server, we’d converted all layouts to themes and styles and all PCs were replaced with new ones and the server was connected via Gigabit Ethernet via an HP Procurve switch (great backplane on these). Within a day, they were complaining the database was running too slow. Again mostly the GTRR original script steps being the culprit. We have many, many more examples.

I’d be interested to hear other views on this, but our recommendation is now keep clear of Go to Related Record in your solutions.

---

<div class="post-metadata">

**Author:** ![EfficientBizz](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/efficientbizz/32/252_2.png) [@EfficientBizz](https://the.fmsoup.org/u/EfficientBizz)\
**Post date:** [October 2, 2019, 6:38pm UTC](https://the.fmsoup.org/t/r-i-p-gtrr/355/2 "2019-10-02T18:38:34Z")

</div>

I only have 2 Customers with FMServer, running FMS17 on macOS10.14 Mojave for over a Year, there was no issue reported regarding GTTR. Could be that this is PC only.

This ‘Not Responding’ Messages is actually appearing frequently on PC (Win 7 AND Win 10) with my FM16 Runtime. Now, with the knowledge of your report, I’ll check if this message is caused by a GTTR process.

thanks anyway

---

<div class="post-metadata">

**Author:** ![jormond](https://avatars.discourse-cdn.com/v4/letter/j/35a633/32.png) [@jormond](https://the.fmsoup.org/u/jormond)\
**Post date:** [October 2, 2019, 7:36pm UTC](https://the.fmsoup.org/t/r-i-p-gtrr/355/3 "2019-10-02T19:36:04Z")

</div>

We have not had any issues, other than expected performance related stuff, but all of our machines are Mac.

---

<div class="post-metadata">

**Author:** ![Torsten](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/torsten/32/1574_2.png) [@Torsten](https://the.fmsoup.org/u/Torsten)\
**Post date:** [October 2, 2019, 8:06pm UTC](https://the.fmsoup.org/t/r-i-p-gtrr/355/4 "2019-10-02T20:06:36Z")

</div>

All Mac here. I stopped using GTTR when moving to v16 and do not have any code in operations that still uses it. It’s ease of use may come with a performance impact through the relationship.

---

<div class="post-metadata">

**Author:** ![Malcolm](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/malcolm/32/196_2.png) [@Malcolm](https://the.fmsoup.org/u/Malcolm)\
**Post date:** [October 2, 2019, 8:46pm UTC](https://the.fmsoup.org/t/r-i-p-gtrr/355/5 "2019-10-02T20:46:22Z")

</div>

I haven’t seen any problems either.

---

<div class="post-metadata">

**Author:** ![Markus](https://avatars.discourse-cdn.com/v4/letter/m/b782af/32.png) [@Markus](https://the.fmsoup.org/u/Markus)\
**Post date:** [October 2, 2019, 9:39pm UTC](https://the.fmsoup.org/t/r-i-p-gtrr/355/6 "2019-10-02T21:39:32Z")

</div>

we’ve had issues with gtrr back in V3 - where ‘record 0’ could be matched, resulting in a found-set with all records…

Most of the times, we are using other methods to select related records. Although there are many customer solution that utilize gtrr, maybe performance issues…

---

<div class="post-metadata">

**Author:** ![Malcolm](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/malcolm/32/196_2.png) [@Malcolm](https://the.fmsoup.org/u/Malcolm)\
**Post date:** [October 2, 2019, 9:50pm UTC](https://the.fmsoup.org/t/r-i-p-gtrr/355/7 "2019-10-02T21:50:43Z")

</div>

Once burned you never forget 😀.

FMP v3. That’s where I started. Back when v9 was current, I was working on an application that had to transfer records between two files. One was running on a server in Sydney, Australia and the other was running on a server in London, UK. Using GTRR the process never completed. We could mimic the GTRR with a find and it never failed.

Perhaps I learnt my lesson then, as I will modify my code, depending on the conditions the script will operate under.

---

<div class="post-metadata">

**Author:** ![jormond](https://avatars.discourse-cdn.com/v4/letter/j/35a633/32.png) [@jormond](https://the.fmsoup.org/u/jormond)\
**Post date:** [October 2, 2019, 9:53pm UTC](https://the.fmsoup.org/t/r-i-p-gtrr/355/8 "2019-10-02T21:53:45Z")

</div>

I have on my project list to rebuild a search script that uses a lot of GTRR. Should be interesting.

---

<div class="post-metadata">

**Author:** ![Malcolm](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/malcolm/32/196_2.png) [@Malcolm](https://the.fmsoup.org/u/Malcolm)\
**Post date:** [October 2, 2019, 10:10pm UTC](https://the.fmsoup.org/t/r-i-p-gtrr/355/9 "2019-10-02T22:10:37Z")

</div>

One to many GTRR records are easily converted. It’s the many to many GTRR that are a nuisance.

---

<div class="post-metadata">

**Author:** ![AndyHibbs](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/andyhibbs/32/3089_2.png) [@AndyHibbs](https://the.fmsoup.org/u/AndyHibbs)\
**Post date:** [October 3, 2019, 4:18am UTC](https://the.fmsoup.org/t/r-i-p-gtrr/355/10 "2019-10-03T04:18:51Z")

</div>

Agreed Malcom, particularly go to all records in a found set and navigate to the chosen record, say a subset of invoices for a client or job. For simple links GTRR has previously provided a simple, one line navigation tool, but even the simplest link can result in the ‘Finding’ holding message and frustrated users.

Also, great to see references to v3 here, which I believe from memory, was the first relational version along with TCP/IP support back in 1995. Back in the days when FileMaker Server 3.0 was released in 1996 a year after FileMaker Pro 3.0.

---

<div class="post-metadata">

**Author:** ![Markus](https://avatars.discourse-cdn.com/v4/letter/m/b782af/32.png) [@Markus](https://the.fmsoup.org/u/Markus)\
**Post date:** [October 3, 2019, 7:12am UTC](https://the.fmsoup.org/t/r-i-p-gtrr/355/11 "2019-10-03T07:12:02Z")

</div>

(-:

we’ve had an inventory system running on v3 with several 1000 articles. When ‘stock-out’ or ‘stock-in’, the gtrr sometimes picked record-0… was really a mess, happened not every time, hard to detect. At some point, that ‘record-0’ problem was officially recognized (and later imho solved)

---

<div class="post-metadata">

**Author:** ![AndyHibbs](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/andyhibbs/32/3089_2.png) [@AndyHibbs](https://the.fmsoup.org/u/AndyHibbs)\
**Post date:** [October 3, 2019, 7:30am UTC](https://the.fmsoup.org/t/r-i-p-gtrr/355/12 "2019-10-03T07:30:50Z")

</div>

There’s been a few of those Markus, remember the variable problem that entered the variable name if it was null value?

Now THAT screwed up some Finds and systems and was a major argument for using GTRR back in those days.

Oh for slower release cycles and higher quality management. Another favourite topic of mine - Marketing beats Technical every time 😥

---

<div class="post-metadata">

**Author:** ![EfficientBizz](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/efficientbizz/32/252_2.png) [@EfficientBizz](https://the.fmsoup.org/u/EfficientBizz)\
**Post date:** [October 3, 2019, 10:30am UTC](https://the.fmsoup.org/t/r-i-p-gtrr/355/13 "2019-10-03T10:30:07Z")

</div>

_ **Another favourite topic of mine - Marketing beats Technical every time 😥** _  
I’ld say, this is a simple proof of the facts:  
[Bug Report inventory AND Bug fix protocol by FMI](https://community.filemaker.com/en/s/idea/0870H000000fyMWQAY)  
[FMI Whitepaper “Under the Hood” for every new release](https://community.filemaker.com/en/s/idea/0870H000000fy83QAA)  
[Update/Bug Fixes/Maintenance for last 2 FM Releases](https://community.filemaker.com/en/s/idea/0870H000000fyYmQAI)  
[Send FMI SW-Architects to every Devcon (Europe!) every Year](https://community.filemaker.com/en/s/idea/0870H000000kAoaQAE)

---

<div class="post-metadata">

**Author:** ![Markus](https://avatars.discourse-cdn.com/v4/letter/m/b782af/32.png) [@Markus](https://the.fmsoup.org/u/Markus)\
**Post date:** [October 3, 2019, 11:22am UTC](https://the.fmsoup.org/t/r-i-p-gtrr/355/14 "2019-10-03T11:22:10Z")

</div>

Yes… I think we have hit some of them as well…

It is quite common today to priorize ‘form’ over ‘function’ - look at Apple…

---

<div class="post-metadata">

**Author:** ![AndyHibbs](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/andyhibbs/32/3089_2.png) [@AndyHibbs](https://the.fmsoup.org/u/AndyHibbs)\
**Post date:** [October 3, 2019, 11:59am UTC](https://the.fmsoup.org/t/r-i-p-gtrr/355/15 "2019-10-03T11:59:19Z")

</div>

So true. Give me my scroll bars back and buttons that don’t all look the same or hidden in some menu icon that says nothing.

Try scrolling left to right on a spreadsheet without a trackpad.

Maybe start a new forum Markus ‘grumpyoldfilemakerdevelopers.whinge’?

---

<div class="post-metadata">

**Author:** ![EfficientBizz](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/efficientbizz/32/252_2.png) [@EfficientBizz](https://the.fmsoup.org/u/EfficientBizz)\
**Post date:** [October 3, 2019, 1:37pm UTC](https://the.fmsoup.org/t/r-i-p-gtrr/355/16 "2019-10-03T13:37:36Z")

</div>

Markus and I are still missing those legendary 13 minutes from the FileMaker Konferenz 2015 (Hamburg) ‘Keynote’ video which mysteriously disappeared in the post production.  
“How dare you?!” “FileMaker 12 DI-SA-STER” 😂

---

<div class="post-metadata">

**Author:** ![jormond](https://avatars.discourse-cdn.com/v4/letter/j/35a633/32.png) [@jormond](https://the.fmsoup.org/u/jormond)\
**Post date:** [October 3, 2019, 2:30pm UTC](https://the.fmsoup.org/t/r-i-p-gtrr/355/17 "2019-10-03T14:30:37Z")

</div>

Yeah. I’m with you about the many-to-many. I will probably build a modular script to use something like HyperList of a ListOf summary field to grab the id’s, and then a looping find using Extend Found Set. We will see.

---

<div class="post-metadata">

**Author:** ![AndyHibbs](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/andyhibbs/32/3089_2.png) [@AndyHibbs](https://the.fmsoup.org/u/AndyHibbs)\
**Post date:** [October 3, 2019, 4:22pm UTC](https://the.fmsoup.org/t/r-i-p-gtrr/355/18 "2019-10-03T16:22:40Z")

</div>

Ah, FileMaker 12. There’s a thing! First iteration of CSS styles, what a wonder. LOL.

---

<div class="post-metadata">

**Author:** ![AndyHibbs](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/andyhibbs/32/3089_2.png) [@AndyHibbs](https://the.fmsoup.org/u/AndyHibbs)\
**Post date:** [October 3, 2019, 4:29pm UTC](https://the.fmsoup.org/t/r-i-p-gtrr/355/19 "2019-10-03T16:29:31Z")

</div>

Hi Josh

Would be good to know what you end up with. I’ve considered producing a list from the relationship, identifying the serial number of the record the navigation is being triggered within the list and where it occurs in the list, do the find, then go to that record number. Assuming no sorted relationships (absolutely not) and other factors.

We’re using the master detail layouts a lot now, often with a related portal alongside. The use of ExecuteSQL usually means a commit record and loss of focus on the record within the portal, so in this case we are recording the ID of the related record and looping through the portal records until we find a match.

---

<div class="post-metadata">

**Author:** ![jormond](https://avatars.discourse-cdn.com/v4/letter/j/35a633/32.png) [@jormond](https://the.fmsoup.org/u/jormond)\
**Post date:** [October 3, 2019, 4:45pm UTC](https://the.fmsoup.org/t/r-i-p-gtrr/355/20 "2019-10-03T16:45:46Z")

</div>

Yeah, the approach is highly dependent on the use-case, obviously, but it should be interesting. The theory seems sound. To do several, even dozens of finds on local data, should be instant. That is essentially what fmSearchResults was doing. It eliminates any of the cross relationship jumps.

[Next page](https://the.fmsoup.org/t/r-i-p-gtrr/355.md?page=2)
