Rubber Boots Data

Introduction to the series.

Given a FileMaker production setup, such as a given server box and settings, concurrent user count and network connections, what can one do to improve the speed of the database? That is, how can one refactor it: redesign and reprogram to improve speed while keeping the functionality exactly as it is? There are many ways, but before getting into nitty-gritty topics, this post and the series it belongs to, will deal with low-hanging fruit. They give an overview of all the easy tips and tricks that I came across during the past ten years or so.

This post will deal with a couple of ways to prevent FileMaker from unnecessarily generating a layout and performing the necessary calculations while running a script.

 

4 Freeze the window and use empty layouts for long running scripts

Perhaps the most basic means that exist to prevent FileMaker from unnecessarily generate a layout and update it is the Freeze Window script step. It simply does what it it says it does. If a script runs through a set of records, the record data will be loaded and all unstored calculations that are needed for the script will be performed, but all calculations that are needed to generate the layout will not be performed: the rendering of the layout elements, the calculated fields on the layout, portals and filters on portals, show/hide calculations, conditional formatting etc. will not be performed.

4.A Limitations

I am not aware of any limitations to Freeze Window

4.b Price

Unfortunately, using this method comes with the price that it will also prevent the user to see any progress indication. To work around this, every x records, one could show the layout with a Refresh Window script step, followed by a Freeze Window script step ( and a Pause 0,1 seconds in between for the refresh to take place ). But this will cause the entire layout to refresh, which may be slow.

A more elegant approach, and in any case my preferred approached, is to create an empty layout for each table occurrence on which a script may work. A script work layout could contain a Merge Variable through which the user is informed that a script is running and how far the script has progressed. It would still be advisable to use Freeze Window and Refresh Window in order to prevent the window from glitching. Finally, if one opens the layout in a card window that is smaller than the origin window , the user experience may be optimal because it feels like a popup progress indicator.

One downside is that when perform script on server is used ( see an earlier post ) if will be difficult to inform about the progress. It is not impossible, but it would not count as low hanging fruit anymore.

Also, technically speaking, script work layouts and opening card windows do not fall under refactoring because functionality is changed in some way.

One more note to take when using a card window. When the script deletes the record(s) that is ( are ) visible before the start of the script or if the script otherwise changes the current found set, then that may need remedying upon return.

4.C Source

I have seen other developers use this technique in videos, but I do not know who first deliberately proposed this tip. See for example this thread in FMForums. I would not be surprised if it was one of the main reasons to introduce the script step, the other being not confusing the user with flashing screens that show unexpected parts of the database.

 

5 Go to Find mode before changing the layout

There may be situations in which one can not, or does not want to use the measures mentioned in the previous chapter. If that is the case and one wants to do a find on a different layout, then I tended to first jump to the other layout and then go into Find mode. It felt most ‘logical’. In terms of preventing unnecessarily generating layouts, this is obviously not the smartest order. Better first enter Find mode and then change layout, because in Find mode, no calculation fields and some other calculations need calculating.

Make sure to check if anything else happens or could happen between executing the two script steps. I can think of the following : there are additional script steps between the two steps or there are script triggers set on the origin and target layouts. In such cases make sure to check that everything keeps working as it is supposed to.

5.A Limitations

Some calculations that are part of a layout will be calculated anyways, independent of whether the layout is in Find mode or Browse mode. These are at least the calculations for conditional formatting and for show/hide conditions ( the latter only if the Apply in find mode checkbox is selected ) and perhaps others that I am not aware of.

5.B Price

Remember that this chapter addresses the situation that Freeze Window and an empty work layout are no options, then of course, the price that one pays is the user experience. The user may see the execution of the script steps and this may be confusing.

5.C Source

I have seen other developers use this technique in videos, but I do not know who first deliberately proposed this tip. See for example this question from 2019 in the Claris community forum this thread from 2020 in FMForums. For what it is worth, DuckDuckGo’s AI assistant confirms that it is a well known technique without a known first inventor.