2 Replies Latest reply on Oct 25, 2011 9:08 AM by philmodjunk

    New to FMP and FMP11 Application Design



      New to FMP and FMP11 Application Design




      New to FMP and still getting a feel for how things work and best practices to use.

      One question I have is when creating a new application should all DB tables be included in the same FMP file or should they be divided up into seperate files for the application, i.e. membership, accounting, etc...

      I guess my question is, is there a way to call or open muliple FMP files from one FMP session. Using the sample applications, I open Invoicing, then I want to open the Personnel Records file can I open that file from the Invoicing application? This way the user is not going back to Finder to open another FMP file but can do it from within the FMP file already open.

      Also is there a way in FMP to create a custom menu interface without using the drop down menus?

      I have an exisiting application written in another dev tool and i would like to follow the GUI of that application if possible. I know there are a lots of things that can be done in FMP but the menu interface I wouls like to try to recreate. Similar to a QuickBooks menu interface.

      Any ohter suggestions on getting staerted and up to speed fast are welcome...


      Thank You,



        • 1. Re: New to FMP and FMP11 Application Design

          One Filemaker File can hold the equivalent of many files inside the one database - when they are contained in one database they are called tables.  They operate just like having separate, but linkable, files.  That is the way to go for you - have one file 'My Big Database' and have tables inside it, 'Personnel, 'Invoicing', etc.

          You can have them as separate files and link them as well, but there are some significatnt advantages to using the multi-table feature.

          You can have buttons or menu options on each screen to take the user to any other table.

          If you have FM11 you can create custom menus, or you can create your own pop-up lists of values and use those as 'menu' options to drive scripts.

          • 2. Re: New to FMP and FMP11 Application Design

            Historically, FileMaker 6 and older systems could only have one table in each file, so multiple, one table to a file systems were the only way you could set up a relational database with FileMaker. FileMaker has retained the capabilities for such an approach, but has added the ability to keep all the tables in a single file.

            Open File, is the script step or button action you can use to open a different specified File if you want to set up buttons or scripts to open other files. You can also use Perform Script to perform a script in another Filemaker file and this script can both bring that file's window to the front, select a specified window, find data, etc to present the user with data in a specific layout in the other file. Like any other Perform Script step, you can base data to that script in as a script parameter should you need to do so.

            Developers argue a lot over whether to design a FileMaker database with a separate file for each table, all in one file, or with a Data Separation approach that puts the data tables in one file and the layouts, scripts and other inteface elements in a second file.

            With separate files for each table, it's easier to manage any future updates as you can just replace the one file being updated and only need to import data from that one file's table instead of from every table in your system. On the other hand, managing security accounts is more complex as you need identical account names and passwords set up in each file or your user will be asked to enter an account name and password every time the system opens another file. Imagine what it takes to change a user's password in a system of 50 different files... Also, moving data around and controlling what layout is next presented to the user gets more complex as global variables defined in one file cannot be accessed directly from another, you'd use fields with global storage or script parameters to pass such data from file to file instead.

            The Convert to Seperation Model is a compromise between these two approaches. Since most updates are more likely to modify the user interface instead of the data, any changes to the interface file are simple as you just need to swap out the old copy for the new and no data imports are needed. And managing passwords for two files instead of one isn't too terribly difficult--a few simple scripts and perhaps a global field or two can be used to manate account/password changes while making matching changes in the same account of the other file.