3 Replies Latest reply on Jan 22, 2009 1:32 PM by Sorbsbuster

    Huge DB with a container field



      Huge DB with a container field


      Working with someone else's db... fun fun - or not.

      It's 1 db with 1 table, about 3.5gigs in size. Only 600 records

      If I save it without and records, it's 350k, so I assume the one container field is where all the space is being taken up, but all that's in those fields are either jpg's, pdf's, or bitmaps - which none of the ones I looked at were even over 1meg is size.


      How can I find out what is taking up all the space? 

        • 1. Re: Huge DB with a container field

          Howdy MikeyG79,

          Thanks for the post.


          Save a copy, Find/Replace your containor field with blanks and check out the size.  If it's 500K, then you've confirmed that it's the pictures.

          None of the ones you looked at were over 1Meg...what about the others...it doesn't take many bitmaps to eat space.  One single HUGE .bmp would do the job.


          If it's still 3.5gig, recopy the original and blank another field...and on and on.

          • 2. Re: Huge DB with a container field

            I know it's the container fields... there is only 1 container for each record. I tried a script to export them, but only came up with 100megs or so.

            I'm lost as to how FM can blow things up so large (assuming uncompressed storage for containers.) 


            • 3. Re: Huge DB with a container field

              Try this:


              - Create / clone / save, whatever an empty copy of the file.

              - Check its size.  It'll be tiny.  Let's say xMB

              - Find a JPEG file.  First, check it's size - let's say it's yMB.

              - Insert the JPEG into the container filed, and close the file. 

              - Close the file and check its size.  I bet it's w--a--y bigger than (x + y)MB.  Like, (x + 10y)Mb

              - (If no dramatic difference first time, try 3 or 4 times more)

              - Now delete the JPEG from the container, and re-insert it, but this time check the box to 'Store only a reference to the file'.

              - Close and measure again, and the file size will still be a lowly xMB.


              I have no idea why, but FM is very inefficient at storing image files (and others) when they are stored inside the FM file itself. 'Store the reference only' is the way to go.



              Hobby Horse Warning:

              Try right-clicking in the container field and insert an Excel Object for example.  Double-click, and the next thing you know you are playing around with a fully-functioning Excel spreadsheet, which is stored within an individual record in a Filemaker file.  It can be stored, saved, opened and edited in full Excel mode, then closed and saved within the Filemaker file - in fact, within that Filemaker record.  Browse to that record again, double-click the container field, your Excel sheet opens again, and away you go again with more fully-functioning editing. Awesome.  Create another record, insert a completely different Excel sheet (or Word Document, blah blah...) and you're away again, creating and storing a whole archive of document types all within one file!


              I discovered this a few years back, and was totally stunned at the possibilities.  Only two problems:

              - couldn't get anyone at Filemaker to acknowledge that it existed, could be very useful, and would help me solve 'minor' problems, like when double-clicked it would open at various zoom levels that seemed uncontrollable.  In spite of my *raving* about this feature I always had the feeling I had stumbled upon something they'd left in by mistake and I wasn't meant to have found, so I eventually gave up.

              - the resulting FM file size rapidly grew to be absolutely huge - like when you embed JPEGS, as above, for instance.