2 Replies Latest reply on Aug 26, 2011 3:35 PM by philmodjunk

    FileMaker Pro 11 and Crashing



      FileMaker Pro 11 and Crashing


      FileMaker Pro



      Operating system version

      OS X 10.6.x

      Description of the issue

      I have been using FileMaker for over 11 years, from version 4, and I have never had so many databases become corrupted in any version until 11.  I have had almost every database I manage at some point while using version 11 get corrupted forcing me to rebuild.  This is starting to become a pattern and I am getting discouraged that it will eventually happen to every database I manage and create as long as I am using version 11.  I send in crash reports when they happen, but that is a black hole.  I want to have some assurance that this problem is happening to others and that someone is figuring out the fine points and doing something about it.  Rebuilding a database is time that I cannot charge for, and I have had too many non-billable hours dealing with this.

      Steps to reproduce the problem

      There is no telling when the app will decide to crash, and I send in the reports when it does.

      Expected result

      I would expect that FileMaker should not crash EVER, but I know that is not realistic, however it would be nice if I could rely a lot more on it.

      Actual result

      When the app crashes, the file has to be recovered, putting in motion either to rebuild immediately (time permitting) or to keep using until the file can be rebuilt (which it has always had to be so far), but either way I am looking at building in to every project I do an additional number of hours that I cannot bill for. The rebuild often causes problems for the client since it usually happens when I am developing new areas of a file and a rebuild must be done with absolute accuracy or the new file will have issues. So the client must now deal with what was previously an approved and working solution in every respect that has to be used carefully lest there be one field or script step that was not carefully looked over to make sure it was rebuilt exactly.  ( I can compare this to disassembling electronics, where you are putting it back together and there is a tiny screw left over... where was it supposed to go again?? )  Unfortunately one cannot shoot a video of database development to keep in case the file needs to be rebuilt.  Some will say I should be backing up, and I do, but when developing new areas, there is always a number of hours that are lost in returning to 'the last known uncorrupted copy'.

      Exact text of any error message(s) that appear

      FileMaker Pro and unexpectedly quit.

      Configuration information

      This problem has happened on a variety of systems, both Mac and PC.  I cannot pinpoint a common denominator to any occurrence other than I am using FileMaker Pro version 11.



        • 1. Re: FileMaker Pro 11 and Crashing

          Hi ZoXo:

          Thanks for posting.

          Database crashes in FileMaker can have a wide range of causes.  I’m going to need some additional information about how and when the crashing and corruption occurs.


          What is the processor speed and ram on the FileMaker Pro 11 client?

          Is the database hosted by a version of FileMaker Server?  If so, what version of FileMaker Server?  Does FileMaker Server ever crash while hosting the database?

          Do the crashes occur on one database, or on multiple databases?

          What is the file size of the database that becomes corrupted?

          Do the crashes occur only on one machine, or for multiple machines?

          If the databases are stored locally, what folder is the file stored in?


          Please get back to me with this information so I can suggest some possible causes for the corruption and troubleshooting you can try.



          FileMaker, Inc.

          • 2. Re: FileMaker Pro 11 and Crashing

            Two things to keep in mind:

            Regular frequent backups with as many copies saved as is possible--both for files in regular use and also for files undergoing development is a critical requirement for data integrity. (I've recently started using a script that saves a back up copy every 15 minutes while I am doing development work on the file.) When an issue like this occurs, you can work back through the back ups until you find a clean copy, then you only need to add those design changes made since that back up. You can make sure that you have the latest possible data in this back up by saving a clone of it and then importing all the data from the recovered copy into the clone. You would also need to update any next serial value settings on serial number settings so that new records created in this file do not produce nonunique serial numbers. The import and serial number update process can be scripted so that you initiate the script and then check back when the process completes.

            Making design changes to a file that is open and in use by others is dangerous--especially if you are using a client session to modify a hosted file. A network glitch can damage your file if a change you have made is being saved back to the file. Also, you can lock entire tables out during the design change--interfering with users ability to modify data and this can result in scripts that fail to correctly update records. Thus, it is safest to take a copy of the file to your development machine, update it and then deploy it in place of the original.

            Obviously, this requires the same import/update serial number process as importing data into a backup clone. You can minimize this to some extent by using a data separation model where the interface elements reside in one file and the data tables in another.