As you suspect, there are many options—not to mention many pros, cons, and opinions!—for using multiple files. The simplest conceptually (albeit not always simplest to design and implement) is the setup you describe, with separate front-end and back-end (data) files, known in FileMaker parlance as the "Data Separation Model" or just "DSM." Search this forum using that term and you'll find plenty of existing discussion. Here, for example, is a recent thread on that exact topic. Also, the independent (and excellent) FileMaker Forums has an entire subforum devoted to this topic.
Hope this helps get you started.
P.S. BTW, I'm (generally) a proponent of the DSM approach.
The most common reason given for multi-file solutions is the hypothetical ability to swap out a "user interface" file with new interface and business logic and leaving the same data file in place to avoid any need to import existing data to a new file. In practice, data schema changes are just as common as interface and business logic changes, making this a moot point. For folks with certain deployment constraints, like vertical market solutions, it can sometimes still be worth bending over backwards and twisting yourself into a pretzel to enable this anyway. In my own experience, the best reason I've seen for multi-file solutions had nothing to do with modularity or deploying updates, and everything to do with organization and containing long-term corruption. In large enough organizations that run most of their operations out of FileMaker, it can make sense to have multiple interface files for each separate sub-application in use, e.g., production might have one interface file, sales might have another interface file, and fulfillment might have a 3rd interface file. This limits how much developers have to deal with at any one time while working on any one problem, and often takes a tiny bit of complexity out of the users' experiences, too. If the data files are also separated out, then this contains the damage done if one of the files eventually acquires any corruption.
Along similar lines, one good reason to separate is when dealing with external container data. If you move your table(s) containing the container fields into a separate file, you avoid any data migration issues when updating (since the schema associated with just the containers is unlikely to change very much, if at all). The data migration issues associated with containers are ... painful.
One thing that is getting overlooked here is the BIG benefit that you get from multiple files and especially splitting of fairly static data tables into their own file: backups are a lot faster given the nature of the hard-linking in the backup mechanism.
I agree with you in general, JB. OTOH, in our main solution, where the data file is several Gb, it takes 15 minutes to swap out the interface file, vs. the many hours it would take to import data. This enables us to roll out new features and fixes every couple of weeks with minimal pain.
You do have to take care when adding new fields: if the internal IDs get out of sync in the live vs. dev. data files, your scripts, layouts, value lists etc. will point to the wrong fields!
I ckeck this thread, forums on FM and google.
Yep this indeed a 'correct answer'! I just wanted to add my experience with separation. I work with web design and it's the ultimate separation model - the interface is disconnected from the data. This makes it easy enough for me to also think of ways (and whys) to separate FM interface and data. My own experience with FM separation stemmed from clients needing to have a complex interface on the remote desktops and the data on the FM server. This indeed improved speed, as the interface elements did not need to travel in the ether, only the data. Yes, you do need to think slightly differently with this method. It mostly depends on what and why you want to.
Just out of curiosity, how do you deal with the "File X could not be found" issue when you have the interface local?
When you guys implement these multi-file (20+ user) solutions how are you managing users and permissions?
If there is a connection error (because of remote), Mike, then there would be a connection error whether it's separated or not. i.e. all files on the server can give the error when remotely connecting. If the dialog comes up "... could not be found", the user knows that there is no connection.
BTW: we tried a 'sync' before coming up with the separation. It was a nightmare. Semi-infrequent non-connections were a welcome trade-off.
This solution can be on laptop or iPad, as well, though the iPad tends to have more frequent non-connection issues.
You really only have two choices:
- native FM accounts: for that "Security Administrator" from New Millennium is a very handy tool
- or use External Authentication (my preference); that leaves all account mgmt outside of FM
EA of course will not work if you keep the UI file locally.
No, that's not what I meant. If your interface file is local and your data file is hosted, the host could be down but the interface file still accessible. User loses connection. Gets a bunch of "" indicators. How do you deal with that?
Also, you can get the situation where the user points the interface file back to itself when prompted to locate the file. That breaks the file pointer.
We've tried various solutions. Some work better than others, depending on the skill level of the users. Was curious how you do it.
Yes, I knew what you meant, Mike! I'm pointing out that you will get non-connection errors when dealing with remotely accessed files whether you use separation or not.
Don't let them select a file to munge the file reference!