11 Replies Latest reply on Aug 5, 2015 9:05 PM by greatgrey

    resurrection of a suspect system

    PeterWindle

      Hello everyone,

       

      I have been dealing with a filemaker solution for years that has a corruption in it... occasionally there are records that appear blank (they used to appear with question marks in all fields prior to version 13, but since upgrade to 13, all fields are empty)

       

      Various menthods ave been attempted to recover the file, only for it to re-appear with the same problem over time.

       

      Now, most of the time, eveything runs well, but then, randomly and thankfully rarely, a record goes blank.

       

      So, part of my plan to save this system from getting worse is to built a new file, just with a single table in it, which will contain just the same fields as the original file, but this table will be used from now on in order to enter data - in other words, a data separation solution, just for the one table which is problematic. All links within the original file will be changed to point to the new table.

       

      But here is my $64,000 question.

      When it comes time to create the new file, with the new table (for the data only), how safe do you think it would be to copy and paste the fields from the suspect one into a new file/table???

       

      I realise the ultimate "safe" way to do this would be creating all new fields from scratch, but typing them in one at a time will take a LONG time, is copy and paste safe enough in this situation?

        • 1. Re: resurrection of a suspect system
          Malcolm

          When it comes time to create the new file, with the new table (for the

          data only), how safe do you think it would be to copy and paste the

          fields from the suspect one into a new file/table???

           

          Why would you want to jeopardise the new file with any potential

          corruption? Or, to put it another way, if you're prepared to accept the

          presence of corruption, why bother creating a new file, when you already

          have a corrupted file that you can use?

           

          On a more constructive note, you can transfer fields easily. Export your

          table as an FMPro file then re-import that table to the new file. It

          does not carry calculations, summary, etc, but all the names are there.

           

          malcolm

          • 2. Re: resurrection of a suspect system
            PeterWindle

            Malcolm...

             

            Why bother creating a new file when I have a corrupted file I can use...? That's abit like saying, why get a new engine in a car when you can still run the old one... because it's bound to break and leave you in a really bad situation

             

            The field creation by export might be a compromise, at least that will save me some time and avoid any possibly corruption carry over... thanks

            • 3. Re: resurrection of a suspect system
              beverly

              +1 on that. It does not prevent corruption 'in-field', but does help get you all the fields. From there you have to reset your calcs, summaries and other field options. But it does make the fields and data come over. Also, if this is a version-conversion, make the export from the old version into FMP file, convert and then copy-paste the table(s) into the new solution, import the data.

               

              beverly

              • 4. Re: resurrection of a suspect system

                Peter,

                 

                If you have nothing else to do - then make a new file !?

                But I know that's the wrong approach.

                 

                Before going any further make sure your disk is free of errors.

                Then you have to define what makes you think the file is "suspect".

                Blank or "?" records indicate an index problem. Please see <http://fmdiff.com/fm/recordindex.html> for problems and their solution.

                If the problem reappears (over time) and you are sure FileMaker hasn't crashed since the last "repair",

                should be checked here to REALLY know whether there is something wrong with it.

                 

                Depending on the result of this check I can either repair it or have a suggestion how to proceed.

                See <http://fmdiff.com/repairs>.

                 

                Winfried

                 

                 

                --

                Huslik Verlag GmbH • Bgm.-Widmeier-Str. 42 • 86179 Augsburg, DE

                CEO Winfried Huslik - HRB Augsburg 12386 -  VAT-Id. DE127485099

                Phone +49 821 565606, Fax +49 821 565001, Email info@fmdiff.com

                Verify your FileMaker Pro files with FMDiff - http://fmdiff.com

                Linkedin: http://de.linkedin.com/pub/winfried-huslik/2/505/1a1/

                • 5. Re: resurrection of a suspect system
                  BobGossom

                  Peter,

                   

                  In my experience the ?/blank records are usually created at the time of an bad event, not always from internal corruption - although the event itself can cause issues in the file.

                   

                  Note that you can't delete these bad records. You have to sava a clone and import the data into the clone to get rid of them. I'd run the procedure below on the file - it's worked very well for us several times.

                   

                  What do you see when you recover a copy of the the file? There is a technique whereby you analyze the recovery log, which will specify specific corrupt element(s). You can go to your original file, delete/replace those elements, make a copy, and run the recovery again. If you get the file to the state where a copy recovers without incident, you generally are good to go with that file.

                   

                  Then you need to make sure really strict practices are in place. For example, after a power crash, always go to a recent backup.

                   

                  Bob Gossom

                  • 6. Re: resurrection of a suspect system
                    jormond

                    If you have a file that recover finds problems in, would you really want to us it again?  Recover's goal is simply to save the data, at the expense of the rest of the file. If you are continually getting corruption, you need to figure out why it's happening.

                     

                    FileMaker doesn't recommend using a file that itself was "recovered". http://www.filemaker.com/help/13/fmp/en/html/recover.40.5.html#1029844

                    BobGossom wrote:

                     

                    Peter,

                     

                    In my experience the ?/blank records are usually created at the time of an bad event, not always from internal corruption - although the event itself can cause issues in the file.

                     

                    Note that you can't delete these bad records. You have to sava a clone and import the data into the clone to get rid of them. I'd run the procedure below on the file - it's worked very well for us several times.

                     

                    What do you see when you recover a copy of the the file? There is a technique whereby you analyze the recovery log, which will specify specific corrupt element(s). You can go to your original file, delete/replace those elements, make a copy, and run the recovery again. If you get the file to the state where a copy recovers without incident, you generally are good to go with that file.

                     

                    Then you need to make sure really strict practices are in place. For example, after a power crash, always go to a recent backup.

                     

                    Bob Gossom

                    • 7. Re: resurrection of a suspect system
                      BobGossom

                      Joshua,

                       

                      With this technique you don't use a recovered file. You run recovery on a copy. The recovery log indicates the corrupt elements. You delete/correct the corrupt elements in the original file, make a copy (again) and recover the second copy. You can do this process for as many times as it takes to clean up the original file. Once recovery reports no errors, you can be pretty confident in the original file, which has never had the recovery process run on it directly. FMI engineers have, at least in personal conversations, indicated that if recover doesn't identify any problems you can be quite confident in the file.

                       

                      Note that it was a wonderful developer here in LA, Bob Shockey of the Alchemy Group, that figured out this technique and shared it through our local user group, FMDiSC.

                       

                      Of course it would be best to work in a file that never had any corrupt elements, but sometimes that's not an option.

                       

                      We've used this technique very successfully on production files for at least 5 clients. These were cases where we were called in long after the corruption occured and all of the backups had the same issue.

                       

                      Even if the decision is to recreate the file, clients need to do something while the development is occuring. Working with a file whose bad elements have been corrected is preferable to a file that you know is damaged.

                       

                      Bob

                      • 8. Re: resurrection of a suspect system
                        Malcolm

                        My point, poorly expressed, is that copying suspect material from the

                        old DB is like building a shiny new car and putting the old engine into it.

                         

                        Malcolm

                        • 9. Re: resurrection of a suspect system
                          jormond

                          Gotcha. That makes more sense now when I read your post again.

                           

                          It would still bother me that the corruption is happening. Stray library artifact in the file are expected...but corruption should be rare.

                          • 10. Re: resurrection of a suspect system
                            gdurniak

                            You could also try importing the table into the same file,  perhaps from a merge file,  repoint the Graph,  then delete the old table

                             

                            Note:  question marks and blank records are not uncommon, and have been a nuisance for years. I have discussed this with Tech Support, but FileMaker can't find the cause, because it is not easily repeatable

                             

                            Does your Recover log show anything "changed" ?  Did you re-import all your data into a clone ?

                             

                            I have collected Corruption information here:

                             

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

                             

                            greg

                            • 11. Re: resurrection of a suspect system
                              greatgrey

                              One thing I see missing is no one says anything about being sure the File Maker program itself is not corrupted.