1 2 Previous Next 25 Replies Latest reply on Dec 2, 2015 1:04 PM by gdurniak

    Go 13.0.2 Reporting Corrupt files however recovering finds no corruption

    woodstock_1

      Summary

      Go 13.0.2 Reporting Corrupt files however recovering finds no corruption

      Product

      FileMaker Go

      Version

      13.0.2

      Operating system version

      IOS 7.0.4

      Description of the issue

      Several times now various files on Go 13 have become corrupt. I transfer the file to my computer and open in FileMaker Advanced 13, it also sees it as corrupt. After recovering the file it says it found no issues and am then able to open the file. So is not really corrupt?

      Steps to reproduce the problem

      Normal database use in FileMaker Go, varies (can't consistently do it).

      Expected result

      Doesn't corrupt file.

      Actual result

      Corrupts files (even though it really isn't corrupt)

      Exact text of any error message(s) that appear

      On FileMaker Go Dialog:
      "filename.fmp12" is damaged and cannot be opened. Use the desktop product's Recover command to recover this file.

      After attempting to open in FileMaker Advanced it creates recover log:
      Timestamp     Filename     Error     Message
      2014-01-23 11:10:22.970 -0600     Company.fmp12     0     *** Started consistency check of improperly closed file, total of 1466 block(s) to check
      2014-01-23 11:10:23.020 -0600     Company.fmp12     8432     Page 1449 marked free but not in free list
      2014-01-23 11:10:23.024 -0600     Company.fmp12     8432     Page 1450 marked free but not in free list
      2014-01-23 11:10:23.024 -0600     Company.fmp12     8432     Page 1451 marked free but not in free list
      2014-01-23 11:10:23.024 -0600     Company.fmp12     8432     Page 1452 marked free but not in free list
      2014-01-23 11:10:23.024 -0600     Company.fmp12     8432     Page 1453 marked free but not in free list
      2014-01-23 11:10:23.024 -0600     Company.fmp12     8432     Page 1454 marked free but not in free list
      2014-01-23 11:10:23.024 -0600     Company.fmp12     8432     Page 1455 marked free but not in free list
      2014-01-23 11:10:23.024 -0600     Company.fmp12     8432     Page 1456 marked free but not in free list
      2014-01-23 11:10:23.032 -0600     Company.fmp12     8432     Page 1457 marked free but not in free list
      2014-01-23 11:10:23.035 -0600     Company.fmp12     8432     Page 1458 marked free but not in free list
      2014-01-23 11:10:23.037 -0600     Company.fmp12     8432     Page 1459 marked free but not in free list
      2014-01-23 11:10:23.039 -0600     Company.fmp12     8432     Page 1460 marked free but not in free list
      2014-01-23 11:10:23.042 -0600     Company.fmp12     8432     Page 1461 marked free but not in free list
      2014-01-23 11:10:23.044 -0600     Company.fmp12     8432     Page 1462 marked free but not in free list
      2014-01-23 11:10:23.046 -0600     Company.fmp12     8432     Page 1463 marked free but not in free list
      2014-01-23 11:10:23.048 -0600     Company.fmp12     8437     ERROR: Page 1464 invalid previous page link 1346
      2014-01-23 11:10:23.051 -0600     Company.fmp12     0     Reset maximum block sequence number to 471957
      2014-01-23 11:10:23.053 -0600     Company.fmp12     805     FAILED consistency check, error 805




      After recovering database dialog:
      "Recover built a new database without detecting any problems. The new database is safe to use, though you should monitor the results carefully and make sure to keep up-to0date backups of you databases.

      Recover results:
      File blocks: scanned arnd rebuilt 1444 blocks, dropped 0 invalid data blocks.
      Schema: scanned fields and tables, 0 items modified.
      Structure: scanned, 0 items modified.
      Field indexes: rebuilt.

      Configuration information

      Have many ipads, all with Go 13.0.2 , has happened on 3 so far.

      Workaround

      none, have to "recover" and install new copy of file on ipad.

        • 1. Re: Go 13.0.2 Reporting Corrupt files however recovering finds no corruption
          philmodjunk

               After recovering, are you putting the recovered copy back on your iOS device?

               The recovered copy is different from the original even if it reports that no problems were found so that may explain what you are seeing.

          • 2. Re: Go 13.0.2 Reporting Corrupt files however recovering finds no corruption
            woodstock_1

                 Usually putting a new clone of the file on device rather then the recovered copy. Though have put a recovered copy back as well. Never had any issues like this with Go 12.

            • 3. Re: Go 13.0.2 Reporting Corrupt files however recovering finds no corruption
              philmodjunk

                   I'm seeing a number of very frustrating and irritating, but nearly impossible to reproduce issues with FM GO 13. My next stop here is to start my own issue report documenting them as best I can.

              • 4. Re: Go 13.0.2 Reporting Corrupt files however recovering finds no corruption
                ryan.thompson

                     I'm seeing the exact same error message with my company's deployed file, and am also finding that recovery finds no errors. It seems to be associated with users running a script on their local file that sets fields on our hosted file and that deletes/creates records and sets field on their local file, perhaps associated with poor connectivity. Our programming around this is virtually unchanged from FM and FMGo 12 but we're seeing this error consistently from our deployed files since moving to Go13.

                • 5. Re: Go 13.0.2 Reporting Corrupt files however recovering finds no corruption
                  philmodjunk

                       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".
                  2.      
                  3.           Recover does not detect all problems
                  4.      
                  5.           Recover doesn't always fix all problems correctly
                  6.      
                  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).

                  • 6. Re: Go 13.0.2 Reporting Corrupt files however recovering finds no corruption
                    woodstock_1

                         My file is on 60 sales people's ipads across the country. It never crashed during development. Have never run recover on it.  The issue am having isn't with recovering, it is with the file becoming "corrupted" on the ipad.

                         RT looks like the same issue I'm having.  This does seem to happen when the user has a poor connection, the local file can get corrupted easily on FileMaker Go. Unfortunately this happens at least once per day for one of them. 

                    • 7. Re: Go 13.0.2 Reporting Corrupt files however recovering finds no corruption
                      philmodjunk

                           My point is that recovering the file and getting a report back that "no problems were found" does not mean that your file is not damaged, only that the recover process could not find that damage (if any exists). And a crash is not the only way that might result in a damaged file.

                      • 8. Re: Go 13.0.2 Reporting Corrupt files however recovering finds no corruption
                        cmaning_1

                             I am experiencing the same corrupted file issue in our FM Go solution.  Our solution is deployed to about 100+ users.  We are using a data separation model: UI file and multiple data files to enable minimal size updates/syncs.  All files are stored in Go.  A hosted file on FMPro server is used for downloading updated records to the data files.  Everyday a user reports that they are getting an error message stating one of their data files in FM Go is corrupted.  It's not always the same file that is corrupted.  

                             What are the causes of corrupted files and is it related to the iPad hibernating or switching to another app while the UI file is communicating to one of the data files?  Then will a single file solution eliminate corruption?

                              

                             We are using FM GO 13.  Databases developed in FM Pro 12.

                        • 9. Re: Go 13.0.2 Reporting Corrupt files however recovering finds no corruption
                          TSGal

                               cmaning:

                               Thank you for your post.

                               How are the users updating the data?  Is it through a script?  Or, are the files being copied to the individual iOS devices?  If the latter, make sure users exit out of FileMaker Go before copying the file.  Otherwise, if users still have the old file open, there may be data in temporary storage, and when it writes to disk, FileMaker Go knows where to write the data in the old file, which may not be the same in the replacement file, thereby corrupting the file.

                               Assuming the data is being imported through a script, how long after working with the files do the users report the file is damaged?  You also mentioned it happens with different files.  Is there one file that becomes more damaged than others?

                               Any other information you can provide to help me replicate the issue would be helpful.

                               TSGal
                               FileMaker, Inc.

                          • 10. Re: Go 13.0.2 Reporting Corrupt files however recovering finds no corruption
                            cmaning_1

                                 Thank you TSGal for responding.

                                 Updating records:  There is a connector file in FM GO that has TOs from the hosted database on the server and TOs from the data files in Go.  The connector file imports records from the hosted databse to the data files on the iPad via the TOs.

                                 Updating files:  There is another file called download that only has TOs from the hosted database that contain records with container fields.  It does NOT have TOs from other local files in FM GO.  The container fields on the hosted database contain the .fmp12 files.  The script exports the .fmp12 files from those container fileds to FileMaker Go.  Thus replacing existing files.

                                 Should users close FM Go before starting the process of downloading files and records from the hosted database?

                                 We are seeing the corruption take place primarliy with two files that have records downloaded to them from the hosted database as part of a weekly update. Again, the records are downloaded using the connector file.

                                 We are unable to determine with the corruption takes place.  I have personally witnessed the corruption error message only when I re-open FM Go after it has hibernated.

                            • 11. Re: Go 13.0.2 Reporting Corrupt files however recovering finds no corruption
                              TSGal

                                   cmaning:

                                   Thank you for the information.

                                   You don't need to exit out of FileMaker Go if files aren't being replaced.  Just make sure users are not using files that are being replaced.  This definitely applies to users who have hibernated, as FileMaker Go will try to connect to the previous file and it could lead to loss of data or corruption.

                                   Do the users initiate the download of data?  If so, you may want to make sure all other files are closed, and only open the files that need updating and then close them.

                                   TSGal
                                   FileMaker, Inc.

                              • 12. Re: Go 13.0.2 Reporting Corrupt files however recovering finds no corruption
                                Cable2001

                                     I've noticed the FileMaker Go seems to get corrupted if you so much as look at it funny. VERY unstable product but it's all we have right now.

                                     Some tips I've found minimize the problem:

                                       
                                •           Be sure users always use an "Exit Application" function instead of tapping the home button.
                                •      
                                •           Don't let the app go to sleep while open.
                                •      
                                •           Be sure you have a "commit records" step after every script step that changes a record. Apparently Go is bad at closing records and that can lead to corruption.
                                •      
                                •           Close external files within your application as soon as you no longer need them.

                                     It can be hit or miss. For example, I have a solution out right now that three users have. One of them gets a corrupted file every single day. The other two haven't had it happen yet.

                                • 13. Re: Go 13.0.2 Reporting Corrupt files however recovering finds no corruption
                                  cmaning_1

                                       We think we have narrowed down the cause of the corruption in our scenario.  The script to download files ends with a dialog box that tells the user their download completed.  The script wouldn't complete until the user selected "close" in the dialogue box.  There seemed to be a correlation between  the iPad auto-locking while the dialogue box remained open(therefore the script is still running).  I changed the script to eliminate the dialogue box and have the user brought to a specific layout at the end of the script.  This allows the script to complete and  eliminates the script still running in the event the iPad auto-locks.  The users usually start the download and walk away so the iPads inevitably auto-lock. 

                                       So far after 27 users downloading, no corruptions.  We would usually have 3-4 corruptions on that sample size. 

                                  • 14. Re: Go 13.0.2 Reporting Corrupt files however recovering finds no corruption
                                    Cable2001

                                         Interesting. I do have scripts that end with dialogue boxes, but my one troublesome user swears he is using the exit script, which can only be triggered after any dialogue box closes. Definitely something to keep in mind.

                                    1 2 Previous Next