Catching up with regressions is the hardest part of development - for me.
2 Likes
Not a regular one, but worth mentioning none the less. Client running Mac Mini recently updated to Mojave and FMS 18. Over a week ago, after a visit from their IT support, we get reports of FileMaker ‘Cannot write file to external storage’ and, of course, we’d now also lost our remote access.
After a week or more to get our access back, finally logged back in and checked everything on the (secure) folders, access privileges and couldn’t find anything wrong.
However, upon closer inspection, realised that the backups had all stopped, just over a week ago, ‘gulp’ and traced it to IT having decided to rename the hard disk from ‘Macintosh HD’ that we’d left it at to something they preferred.
The FMS backup paths are text strings and it appears (somewhat obviously) that the external storage uses the original path until FMS is restarted. The type of brittleness we try to avoid when creating our solutions .
1 Like
my favorit is forgetting about the trailing return character in the result of filtervalues, would be nice to get an option to turn this off
another favorite is forgetting the quotes in defining mouse-over text (among others), when characters/reserved words are used… all lost
Hi @AndyHibbs,
What issue are you seeing with GTRR on FileMaker 16?
Server side? Client side? Combination?
Thanks.
Hi Tony
It is the ‘Finding’ messages that have been reported many times in different places. Both we and some of our developer clients had to make programmatic and structural changes due to the poor performance of GTRR when moved from FMS 15 to 16 and upwards.
We recently took a customer who has their server and PCs on a traditional LAN and upgraded from v14 to v17 with brand new server and client hardware. We converted their complete system to themes and styles and carried out some ExecuteSQL optimisation, but they still reported reduced performance in many areas.
We’ve a number of systems that have grown organically, with their roots in pre-Internet systems and we’re doing our best to make much shorter anchor/buoy chains, or dedicated short chains for specific features, or abandoning GTRR entirely and just use key field finds to overcome this.
Kind regards
Andy
1 Like
The following two items do not concern me, but I figured I would still mention them:
- variable name typo (something MBS helps with on a mac)
- having a watch in the data viewer that sets a value via a
Let ()to a$variablethe script you are debugging uses (expecting another value obviously)
Absolutely 
Regarding global variables there is a method that helps. Instead of having many of them, use a single global var that contains JSON where each of the globals is replaced by a key. Typo should be easy to spot !
2 Likes
Is there a performance impact in doing so?
Hum,
I don’t think so. I implemented this once to manage tabs. For most of the tabs, activating one needed some process be done. Each tab name was a key in the JSON string stating if the tab was dirty - needing to do the process - or not. Moving to a different records would set all flags to dirty, switching to a specific tab would set dirty to false once process executed. When a tab was selected, if the record didn’t changed then the process was not done !
1 Like
interesting idea:
- stopps the clutter in the dataviewer
- can be used to group variables
- cleaning up is one step
…
I’ll defenitly give it a try
thanks for the input
1 Like
one that happens every now and then:
- do some changes in a script
- if the script is unsaved, a warning will not appear under every circumstance, ie when clicking on a button
– so, one will try to find out, why something that was ‘changed’ does not work…
4 Likes
Sorry to wake the dead ( I’ll have to check my settings because I’m not receiving any notifications of these topics) but I’m interested in your GTRR performance problems.
Are you trying to locate large numbers of records; or a small number of records within a large number of records; or are you working across a long chain of TOs?
I consider GTRR to be a “use with caution” function. It is essentially a convenience function because the same result can be achieved with a find.
2 Likes
Hi Malcolm
Sorry for the slow reply. The answer is probably ‘all of the above’, mainly because GTRR has always worked so great since its inception.
It is a change of character issue, rather than why we are doing it. According to FileMaker Help, GTRR was introduced in v6 or earlier (I can’t remember exactly when) but even so, up until the release of v16 that was 15 years of reliable service and 17 years to today. We even used to laugh at people who used find rather than GTRR, as GTRR worked so well.
With the changes to the FileMaker engine and the way network traffic is handled, we feel that GTRR should almost go on the deprecated list, along with many other old features of FileMaker that work brilliantly on a local network, but are hopeless when hosted on the Internet.
I presented in a meeting with FMI a while back and to highlight why we are hosting and streaming FileMaker, started the meeting by carrying out a sort on a list using a field that was 2 hops away from the layout source table (i.e. there was a link TO in between them), first on my local copy of FileMaker Pro and after our streamed copy - same layout, same server, same connection. The sort took about 2 minutes using the streamed version, the meeting was for an hour and the local copy of FileMaker completed as the meeting concluded. Not good design for a WAN solution agreed, but sometimes this type of functionality is needed. The same could be said of Summary fields and ‘Replace Field Contents’ that can grind a system to a halt.
Another common mistake I have to admit to, either doing a find or set field. For context we use ‘kID’ for our key fields, then say ‘kIDOrd’, kIDQte, or even ‘kIDOrder’, ‘kIDQuote’ etc. for foreign fields and the times I’m scripting from say the Orders table having recorded ‘kID’ in a variable and, for instance in the Order Line Items context, set field ‘kID’ rather than ‘kIDOrd’, hence finding on or overwriting the subtable key field rather than the foreign key field. My built in trait of focussing on the bigger picture and often making stupid mistakes within the minutiae, but perhaps also part of running a company and employing people may have something to do with it. LOL
I have seen a lot of systems that are “all singing, all dancing” on the LAN that struggle to find their feet on the WAN.
I’ve done a lot of work with systems that had to work on the WAN and GTRR is a basic part of the toolkit. We’ve seen enormous improvements in transfer speeds across the WAN from v14 onwards. In that respect, it’s getting easier, in my opinion, to provide a rich UI on the WAN.
GTRR, Summary Fields and Replace Field Contents all have the potential to impact many records, so you have to factor in the load that comes from transfer times and processing times. You can easily load a layout up with objects that will kill performance and I suspect that is what you’re experiencing.
Bottlenecks can exist in LAN and WAN and VPN. Especially in smaller companies with networks that grew over time, no planning or documentation, I learned that things to look for are
- old cables (sub-Gigabit)
- damaged cables
- deprecated equipment (switches, routers, wireless stations)
- bad configs (i.e. IP address generation)
Performance improvements can be dramatic after correction of the above error(s).
The upload speed of Internet connections can be a serious bottleneck.
For home office I recently switched from a asymmetrical DSL line (40 Mbit/s down / 8 Mbit/s up) to a symmetrical 50 Mbit/s up / 50 Mbit/s down line. This improved speed dramatically when accessing FM over VPN. Complex layouts with many related tables and lists become workable over VPN.
No Malcolm, not the layouts or objects, some fundamental tasks during an FMP/FMS connection are not optimised for WAN usage, hence my comments. Try doing a replace field contents on a minimalistic layout on a few hundred thousand records as an example (don’t do it, LOL!). PSOS is part of a solution to some and we get around it with our streaming and huge bandwidth between server and client.
The point I’m trying to make is that not all FileMaker’s feature set can be used any more due to compromises for WAN optimisation.
Torsten, and not everyone can obtain decent Internet, particularly people working from rural locations.
That is true. I sometimes forget about this since we are spoiled with an excellent mobile infrastructure here in CH.