3 Replies Latest reply on Sep 8, 2014 8:59 AM by philmodjunk

    Huge filesize even when empty



      Huge filesize even when empty


      I was helping a client out with a database tweak, and created a new layout. I wanted to email it out to him so I could copy paste the layout (we were screen sharing).

      I quickly realized the database was ~180mb. I deleted everything except the layout and the 2 tables i needed, with about 15 records in one table, and 2-3 in the other. Filesize was still 100mb (the other tables were big and had upwards of 30,000 records).

      Perplexed, I deleted all the scripts, all the value list, and set all the themes to the most basic possible. Barely any change in filesize. I tried save as compact, and it brought it down to ~90mb. 

      Frustrated, I deleted EVERYTHING. User accounts, value lists, layouts... There's just nothing left. Still at 87mb.

      Here is the DDR report, I'm not used to working with them but not seeing anything obvious as to what is taking up all this room. I tried Recover, save as compact... Still nothing.

      If anyone could help that would be much appreciated

        • 1. Re: Huge filesize even when empty

          Did another recover, and I was presented with a new table called "Recovered Libary" with two fields, one of them being a container that turns out had a ton of large pictures in each record!

          How can I clear this out from the original database? How can I know where it came from?

          • 2. Re: Huge filesize even when empty

            The index files may have gotten corrupted. If so the images were still in the database, you just couldn't see them.   Recover would rebuild your indexes, and if it was just an index problem then it would be ok to use the file.  If there was any other type corruption, then it would be recommend to use a backup copy.

            Another reason may be a bug in your database design.  If you allow a parent record to be delete without the child record you would end up with orphan records.  You can verify this from the relationship graph. Check "Delete related records in this table when records are delete in the other table.

            In either case you will have to delete each unwanted record.  You could script the deletion of these records but I would suggest making backups before, incase your script deletes the wrong records.

            • 3. Re: Huge filesize even when empty

              The fact that recover produced a table that did not exist before the recover suggests that your original file is damaged and you should either stick with the recovered copy (and delete that added table) or revert to a back up copy that does not produce this added table when recovered.

              Two other options that you can play with when a file seems excessively large:

              Save a compacted copy using the Save a Copy as menu option.

              Save a clone (No records) copy of your file and then import all data from your current file into the clone.

              You might save a compacted copy of your unrecovered file and then recover this copy to see if you still get the extra table in the recovered copy.

              Things to keep in mind about Recover:

              While Recover almost always detects and fully corrects any problems with your file...

              1. The recovered copy may behave differently even if recover reports "no problems found".
              3. Recover does not detect all problems
              5. Recover doesn't always fix all problems correctly
              7. Best Practice is to never put a recovered copy back into regular use or development. Instead, replace the damaged file with an undamaged back up copy if this is at all possible. You may have to save a clone of the back up copy and import all data from your recovered copy to get a working copy with the most up to date information possible.


              And here's a knowledgebase article that you may find useful: What to do when your file is corrupt (KB5421).

              Caulkins Consulting, Home of Adventures In FileMaking