6 Replies Latest reply on Sep 13, 2013 12:50 PM by jormond

    Why a recovered file still had issues

    DDoughtie

      I thought this might be of use for anyone running into the issue where their Verifications are failing on FMS yet the databases tend to stay up (for the most part). I got this message when i tried to determine why files were failing verification after migrating from FMS9 to FMS11. (I used Recovery on the file). " WARNING: problems were detected while recovering the database. The recovered file should NOT be used going forward; copy only the most recent work from it into a backup copy of the original file." This was happening on a .fp7 file that was created with FMP 9 or earlier. When you see a message like "should NOT" you tend to take notice.

       

      The problem was FMP 9 didn't see any problem if you use Recovery. FMP 10, 11 and even 12 see the problem but don't give much insight. I finally poured over the recovery log file in Console and found a vague reference to modifying a calculation followed by some cryptic message about not finding a table key. I looked at the calculation and found it used a custom function. I then opened each custom function and found one had gotten truncated with some gobbledy gook. I fixed it and the one calculation that used the CF. Everything now checks out. So, looks like recovery log doesn't have a way to report directly to the fitness of custom functions. It only reports bad calculations, which may or may not use a CF. The sad part is that this file had been edited for years using only FMP 9 and during the last 3 years they constantly fought with data corruption and had to restore from backup or use file recovery (always using 9 so the bigger issue wasn't being reported). Hope someone finds this useful.

        • 1. Re: Why a recovered file still had issues
          gdurniak

          There were known bugs in FM 10 Recover, where a custom function could get scrambled. Hopefully they are fixed

           

          see here under "FileMaker 10":

           

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

           

          not sure why going from FM 9 to 11 was a problem.

           

          and since Recover is a black box, we really can't be sure what is checked

           

          greg

           

           

          > The sad part is that this file had been edited for years using only FMP 9 and during the last 3 years they constantly fought with data corruption and had to restore from backup or use file recovery (always using 9 so the bigger issue wasn't being reported). Hope someone finds this useful.

           

          > So, looks like recovery log doesn't have a way to report directly to the fitness of custom functions

          • 2. Re: Why a recovered file still had issues
            DDoughtie

            Going from 9 to 11 wasn't a problem. The corruption was caused when it was managed with 9 and served with 9. They never used 10 in this environment and 90% are still using 9. (The corruption was most likely when they had a server melt down after losing its coolant 4 years ago). 9 never reported the issue when the files were verified. The issue is that Recovery, under 10, 11 or 12 can't report corrupt Custom Functions but it will give you a warning that you should immediately stop using the file and go to a backup. Well it just so happened that every backup for the past 4 years had the corruption. 9 never saw it but it might have been serious enough to cause data corruption (they would get data corruption if you attempted to manage the fields and calcs when logged into it via FMS. You could only stop the server, edit the file then replace it and restart the server. And sometimes restarting the server gracefully would cause corruption.

             

            Time will tell if the fixed Custom Function will stop the corruption. I'm just providing a clue for people trying to resolve data corruption. They might want look at their custom functions. Maybe the next version will look at custom functions a little different and provide a better report.

             

            Dan

            • 3. Re: Why a recovered file still had issues
              Mike_Mitchell

              Thanks for the tip, Dan.

               

              Mike

              • 4. Re: Why a recovered file still had issues
                gdurniak

                ... and please report it as a possible issue

                 

                http://forums.filemaker.com/hives/1eea103f05/summary

                 

                greg

                 

                 

                > Everything now checks out. So, looks like recovery log doesn't have a way to report directly to the fitness of custom functions. It only reports bad calculations, which may or may not use a CF.

                • 5. Re: Why a recovered file still had issues
                  DDoughtie

                  UPDATE: I finally convinced them to upgrade to FMS 11. The biggest issue we had is that if you attempted to edit the database while it was being hosted the database would be corrupt. Every night the verification would fail. We switched to 11 and we can now edit the database live and the verification works. I suspect the FMS 9 was too old and flaky.

                  • 6. Re: Why a recovered file still had issues
                    jormond

                    Are users on the file when you are editing it?  This in itself can cause data corruption.