3 Replies Latest reply on Apr 16, 2014 9:10 AM by opencirrus

    Container Files

    opencirrus

      My appologies if this has been asked before, but I would like to discuss the merits of file container storage internally versus external (secure storage). First some arguments in my partcular application:

       

      - Files do not need to be secure

      - The database is a document store of many files (although this is not expected to get beyond 50GB) per database instance

      - There is a requirement to be able to bundle / export the database WITH files (remaining in native FMS / FMP), and in this case I do not want to complicate or risk paths to container files. The database (with documents) should remain as portable as possible, (for this reason I have also selected not to use the Data Separation Method, minimising the number of files to bundle)

      - It is not necessary to access files outside the database (direct to a folder)

       

      My question here is to discus why I should use external storage which seems to be the prefered method of container storage in many discussions on the forum?

       

      FM defaults to an internal storage of files, so what are the risks?

        • 1. Re: Container Files
          taylorsharpe

          Storing the binary files externally makes the data file much smaller and it performs better.  Container fields act like web pages where FileMaker does not have to wait for them to load if the data is external.  They just load at their own speed as fed by the OS with minimal impact on FileMaker layout processing. 

           

          You can make external storage unsecure if you want.  But that is not the default, nor do I recommend it for most situations.  The main reason is if you don't take the default secure storage, then you will have to manage the folders where things are stored.  Most people make this simple by dumping everything in one folder.  Unfortunatley, the Mac OS really does poorly when you get a few thousand files in a single folder (Windows Servers do better at this).  So you need to decide via scripting when to add sub folders.  This creates a whole new layer of sophistication.  It can be done, but why?  Just use the default secure storage and FileMaker will manage the folder and sub folders to make sure they do not get too big so as to effect performance. 

          2 of 2 people found this helpful
          • 2. Re: Container Files
            danielfarnan

            Regarding your issue of portability, it is possible to change the storage between external and internal for ease of migration. When you change the storage to internal, FileMaker essentially imports all the files into the database file; when you're ready to deploy and have the file hosted, flip the switch back to external and the files get exported and the container stores a link.

             

            So I doubt it's as thorny a problem as you first envisaged.

            • 3. Re: Container Files
              opencirrus

              Thanks for your answer, I also considered this, however through testing I did not find this to be reliable. File names were not restored correctly when switching between internal and external sources. There were multiple errors and FM removed spaces in filenames and replaced them with underscores.

               

              When deploying to FMS, I found that using the 'upload to server' and 'download' the only reliable way to transfer the datafile and associated container container folders intact without some loss of data or links. This works fine, but I cannot rely on sending the folder structure elsewhere.

               

              However, I have concluded that for now I will use an external secure containers to minimise data file size and transfer speed.