8 Replies Latest reply on Mar 15, 2010 2:58 PM by LaRetta_1

    New Recover process in vs. 10

    StellaLuna

      Summary

      New Recover process in vs. 10

      Description of the issue

      From developer community (and not from FMI directly), I have always heard that one should never use a recovered file even if it says it is fine.  And then I heard that FMI admitted the same at a few DevCons.  Then vs. 10 came out and rumor was it had greatly improved the recovery process (in addition to allowing advanced recovered actions).  Well I am still very dissatisfied with what I am seeing in the messages.  Example: Prior to vs 10, the Recover message said:Recovery is complete. During recovery:3248K Bytes were salvaged0 whole records were skipped0 field values were skipped0 lost field definitions were rebuilt. If you have further problems with this file, call FileMaker, Inc. Technical Support. This told us nothing and I was pleased to see that vs. 10's message was different as: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-to-date backups of your databases. Recovery results:File blocks: scanned and rebuilt 804 blocks, dropped 0 invalid data blocks.Schema: scanned fields and tables, 0 items modified.Structure: scanned; 0 items modifiedField indexes: rebuilt. It also contains a button to open the log directly!  Cool, because usually one can't find the silly logs anyway and they never tell us anything!  But now the logs are different as well and here comes my complaint: The log generated for this last vs. 10 messages says at the end: Recover built a new database without detecting any problems.  It would be safest to copy only the most recent work from the recovered file into a backup copy of the original file, instead of using the recovered file going forward. This goes against what the message says, which says it is okay to use and FMI has again left their customers scratching their heads in confusion on what the heck to believe.  And most customers will believe the recovery message which says it is okay to use.  Why can't you be consistent in your wording and message.  Why can't you tell people they shouldn't use a recovered file in recover log AND message?  I searched knowledge base and can't find any place where this is properly documented for us.  Pretend that your top engineer had a huge, critically important solution which crashed and they had to recover the file and ask them what they would do.  Would they use the recovered file if told it was fine by that recover message?  Just how much better is the recovery process from before? FMI reminds me of a politician - going around in circles on this issue and never really answering the question clearly.  Please do so now for us, TSGal.  And please have them change those messages so they don't contradict each other. :womanvery-happy:

        • 1. Re: New Recover process in vs. 10
          TSGal

          Stella Luna:

           

          Thank you for your post.

           

          Yes, I can see the confusion.  I have forwarded this post to our Development and Software Quality Assurance (Testing) departments for review and confirmation.  I will post when I have more information.

           

          As a side note, Recover does fix a database file a majority of the time, but it is still not an absolute solution.  For people developing solutions, we do recommend using a backup and importing the data from a recovered file.

           

          TSGal

          FileMaker, Inc. 

          • 2. Re: New Recover process in vs. 10
            StellaLuna
              

            TSGal wrote:

            As a side note, Recover does fix a database file a majority of the time, but it is still not an absolute solution.  For people developing solutions, we do recommend using a backup and importing the data from a recovered file.


            But even if someone isn't currently developing in a solution, corruption of existing schema or data could take place, right?  And they may not notice it in their data for quite some time.  So if anyone continues to use a recovered solution which has ever crashed, they risk scrambling existing data (as it is used) and they risk a mess when trying to correct it later. 

             

            It's like playing Russian Roulette - most likely the chamber will be empty but when it isn't ...

             

            FMI should treat the subject seriously and take the public and obvious stance that Recover is only used to correct data for export and then import into clean backup copy.  Anything else is flirting with disaster.  And that's why the Recover message saying, "The new database is safe to use," bothered me so much.  Recover is a serious thing.  That's only my opinion and I appreciate you forwarding it on. :womanvery-happy:


            • 3. Re: New Recover process in vs. 10
              TSGal

              Stella Luna:

               

              I wholeheartedly agree with what you are saying, and that's how I initially read it.

               

              TSGal

              FileMaker, Inc. 

              • 4. Re: New Recover process in vs. 10
                RickWhitelaw
                  

                Well spoken! I've been scratching my head over both the process, messages and logs involved in Recover. Here's my complaint: it's possible to read through the entire log, which can be quite long, see no problems, and then get to the end and have one problem reported. There's no way to actually find the problem itself in the log. Although it's obvious "corruption" can occur, often a problem can be reported because a layout table is unknown etc. . . . in other words, a mistake! A person creates a layout based on a table that later gets deleted . . . shouldn't happen, but does.The log has, as you know, various areas: tables, fields, layouts, scripts etc. I got an error reported under "structure" even though schema, fields, everything before that checked out fine, and there's no way I can isolate the problem based on the Recover log.

                 

                Perhaps I expect too much from the process.

                 

                RW 

                • 5. Re: New Recover process in vs. 10
                  TSGal

                  Stella Luna:

                   

                  Sorry for the late reply.

                   

                  Software Quality Assurance (Testing) agrees with the confusion, and they have sent it on to Development for review.

                   

                  TSGal

                  FileMaker, Inc. 

                   

                   

                  • 6. Re: New Recover process in vs. 10
                    LaRetta_1

                    The message is still incorrect in vs. 11.  The pop-up dialog after recover says that the file is "safe to use although you should monitor the results" and the log itself says, "Recover built a new database without detecting any problems.  It would be safest to copy only the most recent work from the recovered file into a backup copy of the original file, instead of using the recovered file going forward."

                     

                    Most customers will read only the final pop-up message when it says the file had no problems and is safe to use.

                     

                    I would also like clarification on this sentence found always in the recover log (even if no problems are detected):

                     

                    Note: Recover only checks the data blocks of the file and generates a new file from that data.  The Consistency Check checks all blocks of the file, and may find more problems in the original file than Recover does.

                     

                    When someone selects Recover, they would assume it checks everything.  Nowhere does it suggest that a person also run Consistency Check as well.  This sentence suggests that, even if performing a full recovery, it might miss additional problems.  If this is true then Recover should include a Consistency Check when it is executed.  I realize that Server runs consistency whenever it opens a file but that doesn't help at all when a customer is trying to find ALL problems with a file.

                     

                    Can you clarify please?

                    • 7. Re: New Recover process in vs. 10
                      TSGal

                      LaRetta:

                       

                      I'm still researching this, and here is the last relevant information I received:

                       

                      "Consistency check is only checking the low structure of the file.  That is, the blocks order and logic (free space in the block for example), but not their contents. Recover however does check all contents of the blocks as it needs to know enough to rebuild a new database.  Unfortunately, I do not know the origin of the sentences and why it's in there. It sounds like what the customer says is logical, and why don't we check?"

                       

                      When I receive more information, I'll let you know.

                       

                      TSGal

                      FileMaker, Inc.

                      • 8. Re: New Recover process in vs. 10
                        LaRetta_1

                        Thank you - I appreciate that!