


If this is defined as a variable, the variable needs to be defined before the external data source can be accessed. Once that happens, the UI file will “resolve” the relationship and connect. 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. A small UI update can be achieved by replacing a single file not the server. 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. In FileMaker 16, we can have as single UI file that all users login into. 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. Record level security can really bog down a system, so separate data files have serious performance benefits. 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. In previous versions of FileMaker, external data sources were fixed. It provides the ability to have multiple customers share a user interface file but each have their own data files. So, what does that do? How does it work? What does that mean for FileMaker development? What is an external data source? One of the new features in FileMaker 16 is the ability to set an external data source dynamically by using a variable.
