R.I.P - GTRR

Heads-Up!
,
1

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.

2 Likes
2

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

3

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

4

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.

5

I haven’t seen any problems either.

6

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…

7

Once burned you never forget :grinning:.

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.

1 Like
8

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

9

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

1 Like
10

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.

1 Like
11

(-:

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)

12

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 :disappointed_relieved:

4 Likes
13

Another favourite topic of mine - Marketing beats Technical every time :disappointed_relieved:
I’ld say, this is a simple proof of the facts:
Bug Report inventory AND Bug fix protocol by FMI
FMI Whitepaper “Under the Hood” for every new release
Update/Bug Fixes/Maintenance for last 2 FM Releases
Send FMI SW-Architects to every Devcon (Europe!) every Year

1 Like
14

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

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

2 Likes
15

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’?

2 Likes
16

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” :joy:

1 Like
17

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.

18

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

19

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.

20

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.