Skip to main content

Working with Eternal Data Sources

In a multi file solution there will typically be External Data Sources. If you have a Dev environment with Dev External Data Sources named one way, and a Prod environment with Prod External Data Sources named a different way, this situation requires a little attention before it is 360Deploy ready. If you did nothing before running a deployment, your Dev file would be deployed into the Prod environment, but would still be looking for the Dev External Data Sources ( which will either not be found, or perhaps worse, actually resolve correctly, but now you are using the wrong database).

The solution is to use Dynamic Data Sources. Dynamic Data Sources allow us to set an External Data Source to a Global Variable, then set that Global Variable during the Startup script. Whatever we set that variable to is what FileMaker will use to resolve the data source. View more documentation about Dynamic Data Sources here.

Dynamic Data Sources allow us to solve this problem of different data sources between Dev and Prod. First, change your data sources to Dynamic Data Sources. Use a Global Variable for each of your data sources. Then in your startup script, create an if/else branch that will determine whether we are running in the Prod or Dev environment, then set the Global Variable to the appropriate path for your data source. There are two common approaches here:

  1. You can use a naming convention that allows you to programmatically determine the right external data source name.

    For example, let's say I name my main file "MySolution". I would name the external data sources after it: " MySolution_Invoices" and "MySolution_Inventory". In my startup script, I can determine the proper external data source by running: Set Variable: $$invoicesExternalDataSource: Get(FileName) & "_Invoices"

  2. Alternatively, and a little bit less clear, is you can take advantage of the fact that 360Deploy preserves the data from the prod file. So you could store the name of the external data source inside a field in the prod file, and have your startup script reference that field when setting up the dynamic data source. This approach is more flexible, because you could have different files follow different naming conventions for their external data sources, but it's a little harder to follow.