FileMaker Pro 22: Initial Impressions

Demo Files

Minimum version to open the file shown in parentheses.

• GetRecordIDsFromFoundSet.zip  (FM 22)
• JSONParse Sandbox  (FM 22)
• JSON Array Virtual List Reporting  (FM 18)
• Josh Halpern’s Virtual List JSON Bench  (FM 21)

Introduction

It’s been a couple weeks since the release of FileMaker Pro 22 (a.k.a. 2025), and now that the dust is beginning to settle and I’ve had some time to explore and build some demos, my initial reactions are…

1. Wow, this is an amazing, game changing release.
2. Ouch, they just “broke” a bunch of my blog articles — in the sense that behaviors and issues described therein have changed in FM 22.

What this article is not: a general overview. If you’re looking for a general overview Fabrice Nordmann (FileMaker 2025! Explore the New Features) and Wim Decorte (FileMaker 2025 Executive Summary) have written some good ones.

What this article is: a look at some of the features and fixes I’m interested in, including the new GetRecordIDsFromFoundSet (a.k.a. GRIFFS) function, and with particular focus on JSON performance improvements. Also I want to mention a potential problem if you’re on the Windows platform, and we might as well get that out of the way first.

Windows Issue

Update 20 Aug 2025: this issue has been remedied in version 22.0.2 as per the Aug 2025 release note here —https://help.claris.com/en/pro-release-notes/content/index.html

Attn: Windows users — if you have FM/Win 21 installed, when you upgrade to FM/Win 22 it will replace your earlier version. Depending on your situation this may or may not be a problem… it definitely will be a problem if you need to connect to FileMaker Server 20 or have your own reasons for wanting to run both FM 21 and FM 22. At any rate, proceed with awareness and caution. Or hold off on upgrading for the time being to see if Claris remedies this in a v-rev update.

Transactional Window Close

The problem we saw earlier this year in Closing Windows During Transactions has been resolved. Prior to FM 22, when a Close Window script step was performed within a transaction (and from the same window the transaction was opened in), the transaction was reverted, but the Get(TransactionOpenState) function returned 1 instead of 0, indicating the transaction was still open, and a subsequent Open Transaction step within the same script would fail.

In FM 22, under the same circumstances, the Close Window script step now properly and completely reverts a transaction.

Insert Text Max Character Limit

If you’ve ever attempted to paste more than 30K characters into an Insert Text script step, you’ve no doubt encountered the above dialog. Well you are unlikely to encounter it now, because the limit — for Insert Text only, not for any other script step — has been increased to 250 million characters.

And while you’ll still get an error if you attempt to paste more than 30K worth of characters into, say, an Insert Calculated Result script step, you’ll be relieved (I know I was) to see that “cannot” and “exceed” have been separated into discrete words in the error dialog.

(It’s a great start — maybe in FM 23 we can get rid of the unnecessary parentheses? Or better yet, extend the 30K limit to 250M everywhere?)

Note: this feature is partly backward compatible. An Insert Text step populated with more than 30K of text in FM 22 will execute just fine in earlier versions of FM — but if you need to edit the step, you will need to do so in FM 22. Attempting to edit the step in an earlier version will cause the 30K error dialog to appear.

JSON Scientific Notation Behavior Change

A few years ago in JSON Currency Rates Revisited I documented a behavior where FileMaker’s JSON parser was rendering small numbers as scientific notation.  For example, this JSON coming from an API…

…was rendered like so:

Not a whole lot to say about this… people complained. Claris listened.

GRIFFS and GTLOR

A pair of shiny new toys I’m excited about are the GetRecordIDsFromFoundSet (GRIFFS) function, and its corresponding script step, Go To List Of Records (GTLOR). This dynamic duo gives us programmatic control over behavior that was formerly restricted to the black box of a snapshot link — the ability to capture and restore both a found set and its sort order, with the additional capability of being able to choose the window and layout (and, as we will see, in some cases the file) where this restoration takes place.

And note that the function and script step work with internal record IDs, not primary keys or any other field the developer has control over. Internal IDs are hidden serial numbers that exist independently of any fields that you may choose to define, and have the advantage of always existing in every record of every table (and of course, of being unique within a given table). For more information, see this Claris help entry: Get(RecordID).

Today’s first demo, GetRecordIDsFromFoundSet, is based on files created nine years ago for this article: Transfer a Found Set to a UI File. You can read up on the particulars there, but the crux of the matter is that in a separated solution, it is trivial to transfer a found set from an interface file to its corresponding data file, but until now there has been no obvious method to go the other direction (i.e., from the data file to the interface file). Nor has there been an obvious way to transfer the sort order of the found set.

And furthermore there hasn’t been any obvious way to transfer a found set and sort order from one interface file to another interface file. Till now.

Start by opening the GRIFFS_Interface file (in FM 22, obviously) and you will note that you are in a found set of 22 records, and the internal record IDs for that found set are reflected five different ways in the footer.

The entries in the footer come from calculated fields defined like so…

…and correspond to the arguments 0 through 4 used by GetRecordIDsFromFoundSet. The arguments control how the IDs in the found set are rendered.

You are welcome to use whichever argument you are most comfortable with. My go-to is “3” as it returns the most compact result (and is also what snapshot links use under the hood).

Here are some things you can do with the demo… first take a look at the “startup” script in the interface file and note that GTLOR is used to generate the initial found set.

Now sort ascending on city and note that the entries in the footer reflect the change in record ID order.

Next run this script…

…which is constructed like so…

…and calls “go to list of records” in the data file, defined like so…

…and like magic you will find your found set and sort order reproduced in the data file.

Did you notice the absence of a sort indicator on “City” here in the data file? There was a sort indicator in the interface file — why isn’t there one here? Because while the record order has been reproduced, the sort criteria have not. Pressing Cmd-S if you’re on a Mac, or Ctrl-S on Windows, reveals something interesting in the sort dialog.

(And, to avoid possible confusion, this might be a good moment to point out that I defined the “RecordID” field in the Contacts table merely to help see what’s going on with record ids in the demo. Apart from whatever value it may add as a teaching tool, this field is not required.)

Some other things you can do in the demo file…

1. Generate a different found set in the data file and transfer it back to the interface file

2. From the interface file transfer a found set to the reporting file

3. In the interface file run this script to put yourself in a found set of zero records.

4. What about transferring a found set from the reporting file to the interface or the data file? This can be readily accomplished and will be left as an exercise for the reader.

JSON Performance Improvements

Okay if you’re still with me, we’ve saved the best for last. FM 22 introduces a re-written JSON engine, and two new functions: JSONParse and JSONParsedState. Even if you never use these two functions, across the board JSON runs substantially faster in FM 22 than in earlier versions. Simply upgrading to FM 22 will give your JSON processing a significant performance boost.

JSONParse Sandbox

Let’s dive into the JSON demos, and the first one, JSONParse Sandbox, is based on the demo file featured a few months ago in JSON Optimization in FM 21. At the time the goal was to explore ways to boost performance in the pre-22 world.

Now, open the JSONParse Sandbox demo (FM 22 or later required) and you will find three records… the first two examples are of an informational nature and indicate that the same basic (i.e., with no clever tricks) JSON parsing operation takes almost three times longer in FM 21 than in FM 22.

But where things get interesting is record #3. Click the refresh button and see what happens.

No, that’s not a typo. Using JSONParse to cache the input slashes execution time from over 1 minute down to less than half a second. Same input, same code, the only difference being that JSONParse has been added to the mix.

[For a deep dive into JSONParse and JSONParsedState, check out this comprehensive exploration by Mislav Kos: FileMaker 22 JSON Performance Optimizations.]

Data Viewer Experiments

Here are results from various JSONParsedState experiments.

3 and 4 indicate parsed objects and arrays, 0 means “it isn’t parsed and I haven’t tried to parse it”, and -1 means “I tried to parse it but failed”.

Virtual List with a 2D JSON Array

Next let’s take a look at the implications for JSON-based virtual lists. Note: If you aren’t familiar with virtual list, or need a refresher, I can recommend these two articles.

• Virtual List Simplified
• Virtual List Reporting, part 4

For many years I’ve been a proponent of basing your virtual lists on 1D arrays rather than 2D arrays for performance reasons. To see why, open the JSON Virtual List Reporting demo, first in some pre-22 version, and then in FM 22. This particular demo uses a 2D JSON array on the back end, and to see the problem, open it in FM 21 or earlier, and…

1. In the “customer summary” popover, set Year and Month both to “All” and click Generate Report.

Wait a few seconds for the report to appear, and then…

2. Click one of the column headings and note how long it takes to sort.

3.  Scroll all the way to the bottom to reveal aggregate info in the trailing grand summary, and note how long it takes to display. On my machine it takes about 11 seconds and I see a number of “summarizing” dialogs…

…before the trailing grand summary finally appears.

(Even the basic act of scrolling feels a bit sluggish, doesn’t it?)

4. Now repeat the above steps in FM 22. All sluggishness is gone, indicating that 2D arrays are now viable as back ends for virtual list.

Virtual List JSON Bench

And finally we have a benchmark file created by Josh Halpern and shared here with his kind permission. The purpose of this demo is to illustrate how long it takes FileMaker to parse a single “cell” of data from a 2D array, and the measurements here are in microseconds.

To see it in action, open and run the file first in FM 21 and then do the same in FM 22. You will see results along the lines of these clearly showing how much faster the parsing is in FM 22. Thank you Josh, this is a very informative demo.

And I think that’s enough for today.