FileMaker 16: External Data Sources
One of the new features in FileMaker 16 is the ability to set an external data source dynamically by using a variable.
So, what does that do? How does it work? What does that mean for FileMaker development?
What is an external data source?
It provides the ability to have multiple customers share a user interface file but each have their own data files.
In previous versions of FileMaker, external data sources were fixed. Each user had to have their own set of files, or record level security had to be used to block access to other user’s records in one data file.
Record level security can really bog down a system, so separate data files have serious performance benefits. However, if each customer has their own file and there are thirty customers, a small UI change meant that you would have to replace thirty different files.
In FileMaker 16, we can have as single UI file that all users login into. The file looks at who is logging in, dynamically sets the data file name in a variable, and makes sure they only connect to their data. A small UI update can be achieved by replacing a single file not the server.
How it Works
The UI file will not attempt to open the data file until it “needs” it, whether it is because there is a reference to it in a script that is called, or a field from the data source on a layout. Once that happens, the UI file will “resolve” the relationship and connect. If this is defined as a variable, the variable needs to be defined before the external data source can be accessed. This means the variable will most likely be defined in a startup script which the purposely accesses the data file to make sure that relationship is resolved correctly.
That would be scripted something like this:
If [ Get ( AccountPrivilegeSetName ) = “Customer1” ]
Set Variable [ $DataFile ; Value: “file:Customer1_Data.fmp12” ]
Else If [ Get ( Account PrivilegeSetName ) = “Customer2” ]
Set Variable [ $DataFile ; Value: “file:Customer1_Data.fmp12” ]
End if
Go to Layout [ “Data” (Data) ; Animation: None ]
The last line of of the script above goes to a layout based on the data source, forcing the relationship to be resolved while the script is still running and the variable still exists. Alternatively, a global variable could be used. The scope would extend outside of the script, and then the open script wouldn’t need to force the relationship to be resolved right away.
Issues to Consider
While this new feature has remarkable potential to simplify UI development on vertical market solutions, there are some issues that will have to be addressed. All of the ones that come to mind revolve around security.
A way will have to be developed to handle the accounts between the UI and Data file. Do you have all of the accounts in the UI file and then only the applicable accounts in each data file? Or do you have an auto-login in the UI file and some other process for logging into the right data file with the right account?
Another issue is the “Re-Login” script step. Once the connection is made to the data file, it will be fixed until both the UI and Data file are closed and reopened. This means if a user uses re-login to log in as a user who does not have access to the file they are going to remain connected to a file they no longer have access to. Also, what if a user needs access to all of the data files? Letting them pick on login might be an option, but having to close the whole system and start it back up to switch data could become cumbersome for someone managing several customers on a vertical market solution..
Join the Conversation
What potential do you see for this feature? Might it have other benefits? How about other drawbacks? What solutions do you see for dealing with these drawbacks?
11 Comments