5 Replies Latest reply on Sep 13, 2013 9:45 AM by philmodjunk

    Grouped button crashes in script

    JonathonKlassen

      Summary

      Grouped button crashes in script

      Product

      FileMaker Pro

      Version

      Filemaker 11

      Operating system version

      Windows 7

      Description of the issue

      A script for my grouped button crashes the filemaker program (shuts the program off) when performed if the filter retrieves 0 records, yet it works fine if the Button is only one object.

      Steps to reproduce the problem

      group objects and make it into a button to run my navigation -filter-sort script, make it run when it will retrieve 0 records.

      Expected result

      Filter records, prompt me to change the filter options if 0 records

      Actual result

      Crashed Filemaker

      Exact text of any error message(s) that appear

      Nothing, just crashes

      Workaround

      Create a single object button

      script.PNG

        • 1. Re: Grouped button crashes in script
          philmodjunk

               If you create a brand new file and create a brand new set of objects to group into your button to perform a similar script, does it crash?

               Crashing can be due to damage to your file and crashes might damage your file. For both reasons, you might run a recover on your file and see what happens.

          • 2. Re: Grouped button crashes in script
            JonathonKlassen

                 Yeah i gave it a test and it didnt repeat the issue. This problem happened a month ago and i just did a work around by using a single object button. Our auto backups copy over the 2 week old ones so i dont think i have a copy to recover that didnt experience the crash. Could this cause big issues down the road? Im a little worried now since we have put in 6 months of my time developing this program.. Would there be any chance the bug could spread?

            • 3. Re: Grouped button crashes in script
              philmodjunk
                   

                        Our auto backups copy over the 2 week old ones

                   That's dangerous. You need to pull some of your backups into an archive location of some sort on a regular basis. Any number of issues, from a user accidentally deleting a record to hidden file corruption (This is rare) can linger undiscovered in your file for extended periods of time.

                   This isn't due to a living microbe or something spreading through your database file. It's not at all likely to "spread". But a computer file is a "black box" to most of us. We can't see inside to see what is really wrong should it become corrupted. We can only play the percentages and make (and keep) lots of backups.

                   This is not unique to FileMaker database files, it's pretty much true for any file on your computer.

                   Did you run a recover on your file? (You can do this on a recent backup.)

              • 4. Re: Grouped button crashes in script
                JonathonKlassen

                     Yeah we are changing the backup system immediately. What do you mean by running a recover on my file? Would the recovery of recent database have the same corruption since it's under a month old? Also another alternative, would I be able to create a new Database and transfer over all the scripts/layouts/tables over without transferring the corrupted section of the file? What exactly is common known facts about corrupted files?

                     Thank you PhilModJunk, your replies are really helpful.

                • 5. Re: Grouped button crashes in script
                  philmodjunk

                       Take a copy not being hosted on the server. Last night's back up copy is ideal. Launch FileMaker without opening this copy. Select Recover from the File Menu and then select this copy to be recovered. Run a full recover and see what results you get. FileMaker may report that your file is damaged. It may report that no problems were found. It may recommend that you not use the recovered copy or it may tell you that it is probably ok to use.

                       If any problems are reported by the Recover process, it is best to locate an older copy of your file that does not produce such a report when recovered, save a clone (no records) copy of this "clean" copy and then you import your data from your most recent recovered copy of the file to get an undamaged file that you can put back up on your server.

                       But you may not have such a copy available. In such cases, you can use the recovered copy and cross your fingers. (Usually, if recovered and told "ok to use" the file will be fine.)

                       But also keep in mind that your earlier "fix" may have totally fixed the problem. If recover reports no problems found, odds are very good that you are good to go and don't need to do anything more.

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