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:
- Set external data sources
- 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.