10 Replies Latest reply on Mar 24, 2014 11:59 AM by BruceHerbach

    File corruption

    camberol

      Mac OS X 10.9.2. FMP Advanced 12.0v5.

       

      I have been getting intermittent crashes while developing a two file, separated solution. There may be weeks between crashes, although the frequency is increasing. These crashes occur in layout and browse mode. I cannot reproduce most of the errors. In some of these situations I will not be able to close any open window and the quit application menu command will be greyed out. If the script editor is open, I may not be able to close it and the list of scripts may disappear. If scripts remain visible, double-clicking one script may open another. Forcing the application to quit is the only way to resume. Other times the application will just crash.

       

      Sometimes, I will use a script to backup the solution before it crashes or before I force the application to quit.

       

      - Will I be backing up an damaged copy in these situations?

       

      The only bug that can be reproduced is when dragging a new layout part into the layout. An immediate crash almost always results. This will not occur on a new, unedited layout. If I delete the header of an existing layout (which has the bulk of the layout's complex graphics) dragging a new part will not lead to a crash. I have already recreated all objects on this part from scratch and have not been able to nail down any specific object as the source.

       

      I tried several months ago to edit a few layout objects in FMP13 and found that doing so could corrupt those objects. Since then, I have rebuilt the solution from scratch to eliminate the layout object corruption. I wonder if I succeeded.

       

      I always use the most recent backup after these episodes and start over. To my knowledge I have always gone back to an un-crashed backup. All backups are saved as compacted copies.

       

      While dragging the layout part suggests corruption there, the other crashes may suggest corruption elsewhere.

       

      How do I determine where the corruption is? I have saved a DDR and validated the xml with Textmate.

       

      I have rebuilt these files from scratch several times in the past only to find the same behavior cropping up.

       

      Of note, my Samsung SSD seems to have problems that need disk utility on a regular basis to fix. It will be replaced soon.

       

      In rebuilding from scratch, what elements of the corrupted database can I copy/paste or import from the old file to a new one without fear of corruption.

       

      - tables

      - fields (as opposed to tables)

      - scripts

      - layout objects

      - custom functions

       

      Is import better than copy/paste and if so, in what situations?

       

       

      How can I determine if a file has been recovered or crashed?

        • 1. Re: File corruption
          dchabot

          Hi Camberol,

           

          I thinks it’s best for you to replace the SSD hard disk first, and then you can determine if Filemaker is or isn’t the culprit!

          • 2. Re: File corruption
            camberol

            Thanks for the reply dchabot. That is at the top of the list.

             

            With that in mind, I know I'll need to code a new file in the future.

             

            In rebuilding from scratch, what elements of the corrupted database can I copy/paste or import from the old file to a new one without fear of corruption.

             

            - tables

            - fields (as opposed to tables)

            - scripts

            - layout objects

            - custom functions

             

            Is import better than copy/paste and if so, in what situations?

             

            How can I determine if a file has been recovered or crashed?

            • 3. Re: File corruption
              coherentkris

              canberol you asked..."in rebuilding from scratch, what elements of the corrupted database can I copy/paste or import from the old file to a new one without fear of corruption".

              IMHO only the data can be trusted 100%.

               

              Saving your backups as compacted copies is good.. save as clone is better.

               

              I would hazard a guess that the problems with your SSD is at least a proximate cause of the corruption.

              http://en.wikipedia.org/wiki/Proximate_and_ultimate_causation

               

              Detection of corruption usually starts with warnings on file open and the subsequent recover.log files that FM produces.

              FileMaker server consistency check is also very valuable.

              • 4. Re: File corruption
                gdurniak

                A bad HD will corrupt the file, repeatedly. I have done this

                 

                There are no "official" rules for rebuilding safely. The theory is that imports or copy / paste use XML and are therefore "safe", but certain script elements can remain corrupt ( I have managed to do this )

                 

                Try Recover, and check the Log. There is a lot of detail there.  Very often, you can just delete the problems

                 

                I have posted additional tips here:

                 

                http://www.fileshoppe.com/recover.htm

                 

                greg

                 

                 

                > In rebuilding from scratch, what elements of the corrupted database can I copy/paste or import from the old file to a new one without fear of corruption.

                 

                - tables

                - fields (as opposed to tables)

                - scripts

                - layout objects

                - custom functions

                 

                Is import better than copy/paste and if so, in what situations?

                 

                 

                How can I determine if a file has been recovered or crashed?

                • 5. Re: File corruption
                  BruceHerbach

                  My guess is that source of your problems is the SSD.  I would replace it immediatly or work on a different computer until it is replaced.

                   

                  I have found that sometimes you can remove corruption from a file.  This usually involves corrupted items on layouts. The key to this is that the recover doesn't change the original file,  it determines what's wrong and makes a copy of the file with the issues removed.  So you can run the recover process,  look at the log. Go into the original file and  find the items that are bad,  delete them and replace with a new item (don't copy and paste the corrupted item ) and then run the recover process on the original file again.

                   

                  This is an iterative process.  you are done either when you can't remove the corrupted item(s) or you run a recover and get the message that "Recover built a new database without detecting any Problems."

                   

                  If you get to the point that you can't remove the corruption, it's time to build a new file.  Take a look at Greg's link above.  It;s very helpful.  It reference's a Alexei Folger's talk on File Maintance and Recovery.  I attended this a couple of times and had a chance to speak with Alexei about doing this.  She confirmed that the recover process leaves the original file as is and that doing this type of iterative repair on the original file or a copy of the original file can result with the original file being in good/usable shape.

                   

                  HTH
                  Bruce

                  • 6. Re: File corruption
                    coherentkris

                    Bruce... surgical removal of corruption .. interesting.

                    When would this NOT work?

                    • 7. Re: File corruption
                      BruceHerbach

                      I have found that if it's something I can't remove. Layouts are easiest to

                      work with. Find and remove the component. Worst case delete everything on

                      the layout and rebuild. Should keep scripts intact with the exception of

                      goth object script steps. You have put the object names back.

                       

                      If it goes into the relationship graph or field definitions you may have

                      more difficulty.

                       

                      Bruce

                       

                      Sent from my mobile device...

                      Please excuse typos.

                      • 8. Re: File corruption
                        camberol

                        Thanks gdurniak,

                         

                        The link is very helpful

                        • 9. Re: File corruption
                          camberol

                          Thanks Bruce,

                           

                          I ran Recover on both files for the first time and got this:

                           

                          "Recover built a new database without detecting any problems"

                           

                           

                           

                          I looked through the log files after previous crashes and only saw entries like this:

                           

                          "Page XXXX marked free but not in free list"

                          "Reset maximum block sequence number to XXXXX"

                           

                           

                           

                          I will wait for a new SSD and rebuild from scratch when I have the chance.

                          • 10. Re: File corruption
                            BruceHerbach

                            It sounds like your file is OK.  I would definity wait until the drive is replaced before doing any more work on it.

                             

                            Best of luck

                            Bruce