9 Replies Latest reply on Feb 5, 2013 2:16 PM by philmodjunk

    Mystery record has no data; corrupt file?


      Mystery record has no data; corrupt file?


           We discovered a record in a file that showed up as question marks for the data.  In looking at it in Table view, it doesn't even have auto enter information (such as a PK/ID that we give to records) - just question marks.  Exporting the record shows an empty line.  

           The record DOES have a Get(RecordID).  When sorted by that ID (i.e. the default sort order, I believe) the record falls amongst a number of other records from 1/30.  The person who created those other records doesn't recall anything odd happening.  The RecordID for the records above and below this one are not sequential (there are a few missing on either side).  

           Doing a file recovery doesn't list any changes on the summary, nor are there any results when searching the log for the prescribed list of words that Alexi Foldger (of FMI) has recommended:   error|warning|modified|changed|dropped|damaged|invalid.  However, when I search through the log for the table that was affected I do find an entry saying that an index was adjusted and that the new record count is different than indicated (by -1).  And the resulting file doesn't show the mystery record.

           So, the question really is is this record a problem?  Can I just manually delete it from the file?  Or should I go through the recovery process to remove it?




        • 1. Re: Mystery record has no data; corrupt file?

               The recovery does not always remove corrupt records.   I would make a backup first then manually delete the record.  This is also a good time to implement a daily backup system if you haven't already.

          • 2. Re: Mystery record has no data; corrupt file?

                 Did you check the recovered copy to see if the "mystery record" was still there. Recover rebuilds all your field indexes and this normally corrects this issue, but it does not check the indexes for problems, it just rebuilds them so nothing gets reported back to you as having been found and fixed.

                 For More Information see:     Phantom Record, damaged file message, Recover can't detect a problem

                 This is one of many acknowledged bugs that can be found in the Known Bug List thread here in the Report an Issue section of the forum.

                 It can also be downloaded as a database file from:    https://www.dropbox.com/s/jt09b82i0xijbu3/FMP%20Bugs.zip

                 If the recovered copy doesn't have this mystery record, you can try another recover but use FileMaker's advanced recovery options to only rebuild the indexes and not attempt any other repairs to your file:

                 If you have FileMaker 11 or newer, you can use Advanced Recovery options to rebuild your file's indexes:

            1.           With the file closed, select Recover from the File Menu.
            3.           Select "Use advanced Options"
            5.           Select only: "Copy File Blocks as-is" and "Rebuild Field Indexes Now".
            • 3. Re: Mystery record has no data; corrupt file?

                   Worth looking at

              "Ooh! My Record shows just question-marks in all fields, what's that?"

              • 4. Re: Mystery record has no data; corrupt file?

                     In response to Phil, no, the record doesn't appear to be in the recovered file. 

                     To S Chamblee:  is manually deleting the record enough?  Is there larger corruption that this is a mere symptom of, and deleting the record doesn't fix anything?  Does doing a recovery actually fix whatever corruption this might be?

                     I will take a look at those references, Phil and David.  Thanks!


                     --  J

                • 5. Re: Mystery record has no data; corrupt file?

                       You will not be able to delete this record as it does not exist. But rebuilding the indexes will correct the problem and make it disappear.

                  • 6. Re: Mystery record has no data; corrupt file?

                         It is not recommend to use recovered files, but sometime you have no choice if you don't have a backup. 


                    • 7. Re: Mystery record has no data; corrupt file?

                           In my opinion, a recovered file produced with advanced recovery options that only rebuild the field indexes and that "copy blocks as is" should be quite safe to put back into use. This is the one exception I make to the "don't use recovered files" rule.

                      • 8. Re: Mystery record has no data; corrupt file?

                             Well, it didn't complain when I deleted the record.  It appeared to delete it.  And closing and reopening the file still showed the record as being gone.  However, when I did a recovery on the file (no advanced options selected, which I believe implies it does everything), the log file still showed that it had adjusted the index, but nothing was listed in the summary or as a warning, error, etc.

                             I did a manual rebuild (turned indexing off for the offending field, closed the file, went back in and turned it on).  A recovery done on that file (with just the block-copy and index rebuild options selected), showed that there was no index adjustment that was made on that field. 

                             So...what does it all mean?  Do I have to worry about using this file, assuming that I go through and manually fix it?

                             The recovery process, if it doesn't adjust anything at least, mentions that it is OK to use the recovered file moving ahead.  Still not recommended?


                             -- J

                        • 9. Re: Mystery record has no data; corrupt file?

                               It's due to the fact that a full on recover may have made changes that are difficult to impossible to check and confirm that they were the correct changes to repair your file. There's no way to be abolutely sure.

                               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.


                               I make an exception in this one case, because the only things modified are the indexes. "Copy blocks as is" means that the structure of your database should not be modified in any way by the recover process. Essentially, this should be the same thing as saving a clone of your file and then re-importing all your data--the way we used to rebuild all indexes in a file in versions of FileMaker older than Filemaker 10.