FileMaker enthusiasts! We are excited to announce that registration for PauseOnError FileMaker Summer Camp* 2023 opens on Monday, May 8 at 12pm ET.

This year’s event will once again be held at the beautiful Kaplan Mitchell Retreat Center, located in Clayton, Georgia, from October 3 to October 6, 2023.

Last year, we interviewed folks about their experience at PauseOnError. You can listen to those interviews here or you can listen to abridged The Context Podcast versions: Part 1, Part 2, and Part 3. 

PauseOnError’s FileMaker Summer Camp provides an opportunity to immerse yourself in all things Claris, FileMaker, and beyond with a focus on learning, connecting, and having fun. Whether you’re a seasoned developer or just starting out, there will be something for everyone at this event.

Accommodations are limited, so don’t wait to secure your spot. Click HERE to learn more!

*Summer Camp… in the fall? Totally. It’s not just a season, it’s a vibe.

I picked up my first copy of FileMaker 3 and wrote my first little database app in 1998. Twenty-five years later, I still find myself eagerly anticipating the next new release, hoping to try out the next cool feature that promises to keep this business of solving problems with software fun. 

A lot has changed in the intervening years. The product has evolved and made significant transformations, gaining power and features. FileMaker started as a tool that hobbyists and professionals depended on. Today, it is also unequivocally a platform for professional software developers. I can’t think of another development platform with the same legacy and endurance as FileMaker. Many all-in-one database and business application development products have come and gone. FileMaker is still, by all measures, going strong. I think this is worthy of celebration and study.

In the coming days, you will read and hear about many of the cool features that Claris is releasing with FileMaker 2023. There is a lot in this release, and I am going to single out one of my favorites–the OnWindowTransaction script trigger. Note: non-technical readers might want to skip to the next section.

OnWindowTransactions in FileMaker 2023

Here’s how it works per the release notes:

The new OnWindowTransaction script trigger creates a JSON object whenever a window’s transaction completes successfully. The JSON object includes the file name, base table name, record ID, operation, and contents of a specified field (or a field named OnWindowTransaction if none is specified) in the base table for every operation within the completed transaction.

Naturally, I find anything to do with transactions pretty exciting, though I think this one is subtly powerful. New possibilities for audit-logging immediately come to mind. But this feature also feels like the closest thing we have to an events handler that can be bound to our app’s data “objects.”

Imagine if we had a CONTACTS object that is modeled with several related tables like so:

In this example, I have created a JSON object in a field called _JSON. This JSON includes data from the CONTACTS table and its related ROLES and PARTY tables. 

We can then hook up a script to that OnWindowTransaction trigger to do a thing such as publish a message to another file or just show a dialog message with the contents of the JSON payload along with the operations details of the transaction every time a CONTACTS record was created, updated, or deleted(!).

For example, after I modified James Bond’s Contact::name to ‘Jane Bond’, FileMaker fires off a script with the contents of the _JSON field from the CONTACTS table:

The amazing thing about this is that this is layout agnostic. This is a Window-level trigger which, for all intents and purposes, means it will work on any layout. Total. Game. Changer. 

Let that sink in.

Yes, you can probably do this today with a lot of care and effort, but doing this kind of thing with OnWindowTransaction would be a huge time saver–it’s simpler and more elegant. 

It is modern.

FileMaker can now natively publish changes to data. Imagine the possibilities if we could couple this power to a simple pub/sub system or message queue to distribute those changes in a non-blocking way to other FileMaker apps or 3rd party integrations. Conveniently, we happen to write just that thing for FileMaker; it is called SimpleQ, and it is free.

But wait, there is more

Aside from the above-mentioned OnWindowTransaction trigger, we are also getting a bunch of eye-opening features such as the new ability to do callbacks with Perform on Server scripts. There are also dozens of important bug fixes and stability improvements, not to mention the numerous features aimed at scaling Server performance. 

This is a doozy of a release.

I’ll admit I wasn’t sure about the decision to call it “FileMaker 2023” but, in retrospect, it makes a ton of sense. At its core, FileMaker 2023 it’s still very much the FileMaker we all know and love. But juxtaposed with the changes that have come before, this release feels revolutionary–it feels like a release designed for modern software development.

Speaking of modern software development, we’ve previously outlined some of our ideas on the Modern FileMaker Revolution, here, but the gist of it is this: if the legacy FileMaker development is about making monolithic do-it-all database apps, modern FileMaker is partly about lightweight, highly performant apps that work within a network of other applications, be it cloud-based SaaS apps or traditional on-prem business ERPs. Modern FileMaker development practices emphasize ideas around loose-coupling and encapsulating complexity to make things easier to maintain; taken all together, the developer-centric features of FileMaker 2023 like OnWindowTransaction, and callbacks help us do exactly that.

Be warned. The release notes are long, but one thing seems clear–Claris remains deeply committed to the FileMaker product line even as it is working to expand the Claris platform; and, I think, for good reason. Twenty-five years since my first “File…New” command, and years of professional consulting and development work with so-called serious software development stacks later, FileMaker is still the first tool I reach for when I want to solve a business problem. 

Congratulations on a great release, Claris! Learn more about FM2023 here.

There are a few scenarios where you may need to change the filenames for your FileMaker custom apps.

For example, you might be hosting your development copy and production copy on the same server. Since FileMaker Server does not allow you to host two files with the same name you have no choice but to name them differently, eg,“My_CRM” and “My_CRM_Dev”.

Or perhaps you’re maintaining one master codebase on the development server and pushing that codebase to one or more servers with a different name in production. This is a common scenario for businesses that provide custom software for a vertical market using FileMaker and the Claris platform. This also applies to businesses where different locations or offices maintain separate custom apps, but development happens on a single file. In this case, “ERP_Main” on the development server becomes “ERP_ClientA”, “ERP_ClientB”, etc. for a vertical market solution or “ERP_Houston”, “ERP_Jacksonville”, etc. for a business’s multiple locations.

But this can get tricky! If you have a FileMaker solution made up of multiple files, you link them as FileMaker external data sources. If you have “ERP_ClientA” and “CRM_ClientA” files that share schema, you want to make sure that your connections don’t break during a FileMaker data migration.

The good news is Otto supports migrating a file and changing its name during the migration process, making it a preferred tool for data migrations. The other good news is that FileMaker supports global variables for naming external data sources.

Getting started with external data sources

External file references are schema and are defined by specifying the path to the data source in Manage > External Data Sources.

Even though Otto supports changing the filename as part of the migration, it cannot update hard-coded file paths. Whatever you define in the file is what FileMaker uses in the cloned/copied files.

FileMaker 16 introduced the ability to set dynamic data sources, allowing you to  specify a global variable for your data file path:

Cool! Now SolutionA can have a different reference to the data file than SolutionB.

Defining dynamic data source paths

One of the first things a FileMaker solution does on open is to establish its data source path. The key phrase here is “one of the first things.” A dialog will show if FileMaker  is not successful in resolving a path:

Once defined, dynamic data sources cannot be modified in the same session. The solution must be closed and reopened. That is, if your use case is to define dynamic data sources based on the account that logged in, the solution must be closed and reopened to redefine those references. The re-login script step will not be enough.

Here are the rules we’ve found to be successful in defining your paths before FileMaker tries to resolve them:

Use a layout that has no dependencies.

Open your solution to a layout that does not require any links to an external data source. Use a local table and open the FileMaker file to a splash screen layout based on this table. This layout can be blank or have the solution name and company logo. Its purpose is to let you define the external data source before those dependencies take effect.
Starting in FileMaker 12, you can specify the first layout in File > File Options.

Do not reference an external data source in the opening script 

Most FileMaker solutions run a script when the solution opens, by way of the OnFirstWindowOpen trigger. Use the Perform Script to call sub-scripts that will run in the following order:

1. Set external data sources
2. Run startup process

With this script structure, you will avoid FileMaker’s attempt to resolve any external file references as soon as it reads the OnFirstWindowOpen script into the call stack. You can safely refer to dynamic data sources in any subscript to the OnFirstWindowOpen script, such as “Startup” in our example. 

The Set External Data Sources script

There are a couple of ways to define external data sources. One way is to store the file paths as data in a single record table. That will survive a migration.

Another is to namespace the filenames in such a way so that paths can be defined based on parsing the filename.

Whatever method you choose, as long as this script is called before any external data sources are referenced, you will be all set.

Gotchas: Remember FileMaker will look for a data source if needed for a value list or saved Find request.

Startup script

Now that the dynamic data sources are defined, the startup script explicitly opens the supporting files.

This is an essential step, because as detailed in the FileMaker help documentation, “a file is opened with a hidden window via a relationship or a script, this trigger doesn’t activate until a window is created directly. However, performing a script in another file does not activate this trigger in that file even if the script creates the first window for that file.”

Does it get more complicated? Why yes, it does.

We often work with solutions that have complex and variable referenced dependencies. In these situations there is often one file that controls the opening of the rest of the solution. If there isn’t one you can make a special Launcher file that does nothing but controls the opening of the multifile solution.  Or just pick one of your files to serve this purpose. The key point is that every user must use that file — and only that file — to launch the system.

Once you have established which file will control the opening, you can set up an OnFirstWindow opening script that kicks off the controlled file opening process. That controlling script should first establish its own dynamic external file references, by setting the variable(s) as described above, and then calling a Script in other other files. Those scripts in the other files should do nothing but set their dynamic file references (if they have any). They set the dynamic reference variable, and use Open File to lock the reference in place.  You might consider calling those Scripts, “Set References”

Following this pattern will ensure that you are establishing dynamic file references in each file that requires them BEFORE you do anything else.

Once the original controlling script has run through this controlled opening, it can go about doing whatever else it has to do to start the system and put the user in the proper place.

Hello! We’re excited to share that Databuzz is doing some very cool things with Otto, as they’ve recently discussed on their blog.

Databuzz is an FileMaker integration expert and awesome Claris Partner based in Sydney, Australia. They announced support for using Otto Webhooks as an alternative to the PHP files that they supply, beginning with their fmESignature Link product (DocuSign Edition).

“Otto’s built in support for webhooks means you can use Otto to act as the receiver of the incoming requests and then perform additional actions, including creating new records in a FileMaker solution, populating fields with data from the webhook request and performing a FileMaker script.” 

Andrew Duncan, Databuzz

This is exactly the sort of use-case we had in mind when we added the webhook receiver to Otto. You can read the Databuzz guide to setting up DocuSign webhooks with Otto here.
We’re thrilled to see the cool things that Databuzz is doing with Otto and we hope you are too! Click here to read about the other great things Databuzz is doing by leveraging Otto.