ISO FileMaker Magazine

Over one's development career, you'll come across a number of people who "think" they know how something really works. You then proceed to show them some of the cool things they can really do, like a "context jump" within FileMaker. You then smile at their surprise, because what they thought was possible isn't even the start of it.

If you don't even know about, or truly understand, FileMaker's ability to jump from one context to another, then you're missing a critical piece to the FileMaker puzzle. It's one of the ways you break down a complex solution into a more digestible division of smaller parts. This not only makes the Relationship Graph potentially more understandable, but may make your solution more performant.

There are, however, a few big issues you must address as your FileMaker solution becomes more and more complex. One of these is protecting your code against itself. Certain script steps like Delete Record, Delete All Records and Replace Field Contents can have severe consequences. Especially, if performed without confirmation. And even then, accidental clicks is certainly a thing! In order feel really comfortable about using these types of actions you can always "protect" your code from doing the wrong thing in the wrong place. This where you implement either Layout or Context specific checking. This can easily be done when you know how to use FileMaker's internal ID values.

Traditionally, performance in computing has revolved around the optimization of bits and bytes — how many can be saved and how efficiently a task can be accomplished. This principle dates back to the era of computers with only a handful of kilobytes of memory, where maximizing efficiency was critical. Fast forward to today, and the same principle holds true. Despite various ways of achieving the same outcome, the ultimate question end-users continue to ask is: 'Can you make it go faster?'

Enter Perform Script on Server (PSOS), a realm where speed becomes almost a certainty. Here, actions occur where the data is stored, eliminating unnecessary back-and-forth between client and server, with the resulting communication involving updating the client's user interface. PSOS becomes particularly advantageous when a client, perhaps viewing a single record, triggers an action which impacts a significant number of records — say, 20,000. In such cases, leveraging PSOS is imperative.

The challenge with PSOS lies in its somewhat invisible nature, requiring troubleshooting and debugging skills to fully grasp. Equally critical is the task of restoring the current client's context, comprising two essential components: the layout (base table and pertinent relationships) and the found set of records. Thankfully, FileMaker offers a built-in mechanism to handle context restoration.

This video, accompanied by a supporting technique file, equips you with two invaluable scripts — one for obtaining and the other for restoring server-side context. Let's learn how to harness the power of PSOS efficiently and restore some context!