Find answers, ask questions, and connect with our community of business solutions and app users, developers, and partners.
This blog was voted into our Best of FileMaker Blogs-Vlogs by our 45,000+ FMT Members! We are proud to feature Direct Impact’s Weihao Ding.
Do you have a FileMaker solution that you want to sell to other people and are wondering how to maintain and update a solution like that? With FileMaker 16 introducing the ability to dynamically set external data sources with a variable, doing that has never been easier.
Data separation model in a nutshell
To understand the significance of this new feature, let’s briefly talk about the data separation model first.
Data separation is a technique to isolate the data in a FileMaker solution from the scripts and interface. This is done by using separate FileMaker files for the interface and data. Lying in the core of this technique is the answer to this question: how do I continue to develop a solution while my client is using the current version?
With data and interface sitting in two (or more) separate files, you can have your client using the current version of the interface file while developing a new version of it. When the time is right, replace the old interface file with the new one and leave the data file untouched.
Of course there are more benefits to this and we will cover them later in this article when talking about use cases for this new feature.
Why is dynamic data source important
In the past, when specifying external data source, you had to hardcode the path to the data source.
To comprehend the limitation of this, let’s put you in the shoes of a vertical solution creator. Vertical solution creators sell their solutions to their clients. To simplify the updating procedure, some of them will adopt data separation model for their solutions. Data files will be hosted on FileMaker Server they set up for each client. And the interface file will be sent to the device running the solution (an iOS device most likely) to avoid downloading UI data when using the app over the WAN. In this case, the interface file can even take the form of a native iOS app created using the iOS App SDK and being distributed through Apple Developer Enterprise Program or VPP store.
So let’s say you are a vertical solution creator with your solution hosted on 100 different FileMaker Servers. When pushing out a new version of your interface file, you will have to create 100 copies of the interface file, each pointing to their own data file and send them to the corresponding client. It doesn’t sound fun, does it?
With the ability to dynamically set the external data source, you will only need to keep one copy of the interface file and can send them to all of your clients. You can choose to have your client pick the data source when they open the file, or even automatically pick the data source for them if you have that information.
With this article I attached a demo file that shows how to create a solution that will automatically pick the data source based on a user’s login credential.
How do we dynamically set a data source
First of all, we need to have at least one table in our interface file to serve as a starting point. It could be a SESSION table which is used to capture the user login info, or a MENU/PREFERENCES(or whatever you call that table with only one record) table.
We want to make sure all the actions that need to happen before we set the data source variable will happen on a layout based on this table. In other words, do not access anything that uses the dynamic data source before setting the variable. Otherwise the user will get an error message saying data source can not be found.
Next we want to go to File Menu -> Manage->External Data Sources… and add a new data source with a global variable as the file path, as shown in the picture below:
After that we need to write a script to set the data source variable. In my demo file in order to automatically pick the data source I set up a DATA_SOURCE table to store the data file path different group of users should use. So in my script it will take the user’s account name and look up the corresponding data file path, then set the $$dataSource variable with it, as shown below:
If you want to control the setting of data source differently, all you need to do is write your script according to your business logic.
One thing to keep in mind is that once the variable has been set and resolved, changing it again will not have any effect. If that user wants to switch data sources he/she needs to close the file, reopen it and set the data source variable with a different value.
Where else can we use this feature
Besides using it to simplify the deployment of vertical solution’s interface file, here are some other use cases that I think might benefit from this feature:
Dynamically loading relevant data for specific user/use case
Depends on how you segment your data, this new feature may help you in various ways:
Production data vs. Test data (user testing)
When conducting user testing, we can use this feature to plug the interface file that we want the user to test into a testing data file. This will give the user some data to test with, without touching their production data. When the user testing is over, we can plug the production data back in and have the new interface file in production.
Active data vs. Inactive data (data archiving)
Depends on the volume of the data that your solution deal with, some time you might want to move data that is no longer actively used to a separate archive file. Archive data is still important to the organization and may be needed for future reference. In that case, you can plug your archive data file into the current interface file with this feature when you need to reference it.
Data segmented by location (branch offices)
Similar to vertical solution, you might have a solution with users from different branch offices located in different cities or even countries. With this feature you can easily set up launcher file or interface file that allow them to access their own data hosted on their own server.
Allow non-admin users to manage data source
In some cases, the developer might choose to remove the admin access from the file permanently. In the past, without an admin account you can not manage the external data source. But now you can build features to allow non-admin users to manage the data source.
If you keep a redundant server that host a standby data file on it, you can use this feature to switch to this standby server when your production server fails.
This new feature can be invaluable for managing data source dynamically, particularly for data separation model, but also to access various version of a file that might be segmented for different reasons. Like any new feature, there are probably many more use cases. I’m looking forward to seeing how others use this new handy feature.