logo for Gnurps Consulting

diverse talents for custom solutions

Upgrades and the advantages of consolidating multiple files into one

Some Filemaker systems now running in Filemaker 8 or 9 have evolved from versions that were created in version 6 or before. Before version 7, Filemaker allowed only one data table per file, so a multi-table relational database system would have multiple files. A basic sales system would have different files for Contacts, Sales, Sale Line Items, and Product Inventory.

The conversion process from 6 to 7, 8, or 9 is relatively straightforward. The resulting multiple files are almost identical to the originals. But the process of consolidating the multiple files into a single file is more complex and expensive. The following list explains the virtues of consolidating Filemaker solutions into one file.

  1. Navigation scripts are all in one place and you need only one script for each navigation action. In a multiple-file solution, you need a set of navigation scripts for every file. So, for example, a script called “Go to the Contacts File, Data Entry layout” will probably exist in every file, whereas it would have just the one instance in a single-file solution. If you change the navigation script, you have to change it in each file.
  2. Although navigation is the most common example of duplicative scripts, the same can be true of many other scripts in a multiple-file solution. For example, a Page Setup (Print Setup, in Windows) script to set printing to landscape, legal-sized paper, must be repeated in each file.
  3. When you set security access accounts and privileges, you set it only once. In a multiple-file solution, you must set the security for every file. Security settings can be complicated, making the process of changes quite laborious.
  4. In a single-file solution, the user will generally work in only one window. In a multiple-file solution, many windows are open and you either have to manage hiding and showing those windows, or users may get confused or annoyed by the multiple windows.
  5. When a user wants to open the solution, in a multiple-file solution it can be unclear which file to double-click.
  6. Variables, even global variables, don’t cross file boundaries. So variables don't work to transfer information across tables in multiple-file solutions. Variables are an important, fast ingredient of scripts.
  7. You don’t have to keep track of file references, the information that tells each file the locations of the other files. Links between files don’t break because there is only one file.
  8. If you pay a company to host your Filemaker solution on the Internet, you may run into the company’s limit on the number of files it allows in its hosting package. The company would charge extra for the additional files.
  9. If you have very many Filemaker solutions, with the single-file approach you are less likely to run up against Filemaker Server's limit of hosting up to 125 files at one time.

Multiple-file solutions may still be warranted. For example, a file holding images or other container-type data can grow very large. Separating it from the main file can allow easier management of the main file.

Another approach involving multiple files is called "The Separation Model." With this approach, data is stored in one or more, separate, relatively simple files that contain only data, while the system's functions – the layouts, scripts, and most calculations – are stored in a separate file. The Separation Model allows easier upgrades, because the often the functions file can be replaced without any need to change the data file.

The Separation Model is different than the example of having Contacts in a file separate from Sales, which is separate from Line Items and from Inventory. In the Separation Model, the Contacts, Sales, Line Items, and Inventory tables are likely to be in the same file.

One suggested advantage of multiple files is the potential for file corruption with the possibility that only one of the tables gets corrupted while the others stay clean. This might be meaningful if the corrupted file was auxiliary or relatively static. But the files more likely to be corrupted are the ones most often in use and/or most complicated and/or most central to the system's functionality. Potential file corruption is not much of a reason to employ separated files.


Site Map | Contact | Resume | ©2008 Gnurps