1 Reply Latest reply on Apr 23, 2014 7:32 AM by philmodjunk

    FileMaker Pro 12 Closes on Batch Find and Replace

    ZachNigrelli

      Title

      FileMaker Pro 12 Closes on Batch Find and Replace

      Post

           Good morning. We are having an intermittent problem. Normally we do a replace over multiple records by using the key board short cut apple = to replace content in a field. Normally, it will replace the content over 10 records or several hundred.

           Recently a problem has started to happen when we use the short cut. We use the shortcut apple = to do a replace and FileMaker Pro closes. We will wait a few minutes and the replace function will work perfect. What could be making the problem intermittent?

           One thing we did do to try and fix the issue was a file recovery but the problem still exists. Any help would be great. It did not seem like anyone else was having the same replace issue?

            

            

        • 1. Re: FileMaker Pro 12 Closes on Batch Find and Replace
          philmodjunk

               There are no such known issues with Replace Field Contents (apple = should be the short cut for Replace Field Contents--not Find and replace.)

               But while recover usually fixes a problem with your file. It is not always able to do so. Do you have a back up copy of your file that you can test? You may need to save a clone of the most recent back up copy that does not show this problem and then import all your data from a recovered copy of your working file to get back in business.

               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).