1 Reply Latest reply on Oct 28, 2009 9:15 AM by philmodjunk

    Should i go multi files?



      Should i go multi files?


      ok i've made a database system for a client, a single file which manages

      Invoices for jobs
      Site Visits for jobs

      Payments for jobs etc


      Im seeing in a lot of solutions, there are multiple files, im still learning more and more all the time, is there any reason as to why i should go with multiple files? 


      Thanks in advance

        • 1. Re: Should i go multi files?

          There are pros and cons with either approach.


          Pros in a unified file approach:

          it's much easier to manage accounts and privileges

          relocating or renaming the file rarely affects how the database functions



          If the file becomes corrupted, you have to take down, recover/import into clone all the data from all the tables--this can be a lengthy process

          Deploying a new updated copy of the file requires moving all the data from all the tables into the new file.


          Pros for a multi-file approach:

          Any issues with a single file can be fixed by replacing/repairing/updating that one file. This can be a much simpler/faster operation than working with a unified file.

          You can "mix and match" files to produce different variations of the same solution.



          Every file has its own accounts and privileges section. If you have multiple files, you have to define matching accounts in each file in order for filemaker to open each without asking for a password each time.

          Move/rename just one file and Filemaker won't be able to find it--triggering error messages every time it tries to open this file until you either change it back or update your external file references that point at this file.

          There are limits as to how many files you can have open at one time. In complex, multifile solutions, you sometimes have to manage the total number of open files to keep within these limits.