When working with multi-file solutions in FileMaker, sharing variables can be a stumbling block. In this blog, I will explain the process we chose when we built the Button Bar Sort Headers solution. It is one of my favorite techniques for sharing variables when they are needed for field calculations.
What is a multi-file solution? This is most common when using the data separation model, but it comes up regularly in other solutions as well. Basically, a multi-file solution is one where you have more than one FileMaker file integrated via external data sources.
When building the Button Bar Sort Headers solution a couple of years back, we initially tested and configured it for a single file. At that time, we were able to leverage FileMaker’s global variables to store the state and user selected information about what to sort. The button bar script, sort fields, and layout objects would use that information to determine what should be displayed, how they should be sorted, and what the button should look like. One of the key dependencies that makes the button bar work so well is based on Kevin Franks Easy Sorting technique. This worked great for a single file. However, following murphy’s law, the first solution we attempted to implement the Button Bar Sort Headers in wasn’t a single file solution. In fact, it was in a data separated file that used two FileMaker Files. An Interface file, and a data file.
The problem: using Kevin’s Technique meant you needed to set a global variable that is referenced in a field calculation to determine sorting order. This is a great technique and very fast, but how can you share variable information between FileMaker files? With the chart below you can see the availability of the variables, and while the Let function and the local variable obviously wouldn’t work as they are local. The global variable only works within a single file (wouldn’t it be great if there was a variable type with a scope that was solution wide?).
Here are 3 techniques to share variable information between FileMaker files:
Pass them as a script parameter to a script in another file, and then you can declare them in that script via the Let function, local variable, or global variable.
-
This has some overhead and requires you to have a script to in the destination file that does the heavy lifting. Every time you need to update it you need to call that script.
-
Set a field in one of the records of the other file.
-
This is pretty straightforward, once you have a table reference from the destination file, but it can be prone to record locking and it only allows for 1 value for all users.
-
Set a global field in one of the tables of the other file.
-
This works great as it can be referenced via a table reference from the destination file, and it is only stored in the client app, so there is no record locking issues. Ie. It can be different for every user.
-
Because the above problem requires a field calculation, the one I like the best is to use a global field in the Data file. I usually place it in a table titled ‘preferences’ or ‘globals’. It can be set easily from the Interface file by adding a table occurrence in the Interface file that points to the table in the Data file – where the global field will be referenced.
Below is an example of Kevin Frank’s calculation field for the sort order. This is the original calculation for a single file that used a global variable for the Sort_Asc field in a single file. You can see we are referencing the global’s $$SORT.SORT and $$SORT.TOSORT to pass information into the calculation:
This is the updated version using a global field from a ‘globals’ table to reference the ‘gSortDirection’, and the ‘gSortFieldName’ for a multi-file solution:
As you can see we can reference the global field in the same way we had referenced the global variable. The benefit of this handling is that when the global field is changed it updates the calculation. There is a little extra overhead needed to use the global field, so it may not be the best if you have a single file solution, but for a multi-file solution, adding the field and table occurrence is minor in comparison to the benefits.
