10 Replies Latest reply on May 17, 2017 9:38 AM by philmodjunk

    One File or Many

    absalespa

      Good Afternoon,

      Curious if there are any advantages to using multiple files vs one file. Application is sales tracking. Currently have separate files for Customers, Vendors, Sales, Accounting. There will be 3-5 people using the system as shared files - all locally.

      Wondering if I'm structuring this correctly with multiple files - or should I combine into one.

       

      Thank You

        • 1. Re: One File or Many
          mikebeargie

          Mostly all files are done in a single format ever since .fp7 was introduced.

           

          The main reason to have two files now is to use the data separation model, where your data is stored in one file, and your interface to interact with that in another file. That gives you the advantage of being able to roll out interface "versions" without having to disturb the data file. There are other advantages and disadvantages too.

           

          For the above specs though, I'd definitely keep it simple and stick to one file. Although when you say:

           

          "There will be 3-5 people using the system as shared files"

           

          How exactly are you sharing it? a 5-pack AFLT license would be best so you get FM Server to host it. You definitely do NOT want multiple people opening filemaker files at the same time straight from a drive.

          1 of 1 people found this helpful
          • 2. Re: One File or Many
            philmodjunk

            The other advantage to having multiple files is more applicable to larger systems. It allows you to organize your system into modules and this can make updating a portion of your system a bit easier.

             

            On the downside, every individual file has it's own set of account names, passwords and privilege sets. You should password protect access to your solution and keeping matching accounts on all files so that the users don't have to keep entering a password each time the system opens another file in the background is an added chore that you won't have with a single file. If you do choose to use multiple files, try using external authentication to make the job a bit easier.

            1 of 1 people found this helpful
            • 3. Re: One File or Many
              absalespa

              Thanks Mike!

              I have multiple copies of Filemaker Pro 15 for the users. I wasnt planning on hosting it on FM Server. Should I?

              I'm a neophyte on FMP and am trying to keep it as simple as possible. I'm not an IT guy or developer so if there are problems, the simpler the system, the better for me.

              • 4. Re: One File or Many
                absalespa

                Thank You philmodjunk! You are a wealth of information!

                Is the FM documentation a good source to learn about accounts, pswds and privilege sets - or can you recommend some 3rd party training? Obviously, I have much to learn.

                • 5. Re: One File or Many
                  philmodjunk

                  The supplied documentation can be a good place to start, but if you find it heavy going, then start searching for training materials on the topic.

                  • 6. Re: One File or Many
                    Markus Schneider

                    in general, we create as many modules are necessary - but as little as possible..

                     

                    If there are more developers, it's easier because each one can concentrate on one module (not two can be in the structure, not two can work on the same layout, etc.)

                     

                    Modules can be handy in many ways. Scripts can 'talk' to foreign script by using multi-parameters, etc. Drawback is the user-roles/accounts

                     

                    For small solutions, we prefer single file systems

                    • 7. Re: One File or Many
                      bertrand

                      Hello, I always use solutions to several files, from 2 to 10.

                       

                      At least 2 because I sell FileMaker solutions in general to several customers (or I wish).

                      So I have to separate the user data from the data management interface. It allows you to have, for example, menus, parameters, specific languages per user without having to question the data, only the application is concerned. I can modify the application without disrupting my clients.

                       

                      I do one to two updates a year.

                       

                      Recovering data files also allows me to outsource processing for multiple clients by simply retrieving data at a specific time.

                      • 8. Re: One File or Many
                        wimdecorte

                        Some other reasons to split a solution in multiple files:

                        - use a file to store just the container fields (sort of variation of the data separation model), especially if you want to use the remote container feature.  This makes updates to the rest of the solution a lot easier, not having to worry about the container data

                         

                        - split the static data tables (especially if they are big) off into their file.  This helps enormously with backup performance and backup disk space requirements because of the way FMS uses hard-linking for its backups.

                        • 9. Re: One File or Many
                          absalespa

                          Thank you all very much. I believe I'll combine to a single file. Off to learn about de-cluttering the relationships window! Thanks Again

                          • 10. Re: One File or Many
                            philmodjunk

                            ExecuteSQL can be one tool to use to reduce the number of needed "boxes" in your relationship graph. It can also slow performance if used incorrectly so I suggest that you study up on the function and then test carefully with realistic numbers of records in your tables after implementing any such change.