6 Replies Latest reply on Feb 25, 2014 7:27 AM by l_allen_poole

    Novel crashing behavior, seeking suggestions


      Hi all -


      FileMaker 11 Server hosting a database for FM 11 Pro and Advanced clients.


      Here's a mystery:

      I have a table with 13 records. One of these records contains the word "Developer" in an indexed text field.

      In the past, a scripted process successfully & reliably located the "developer" record by performing a Find script step with the search criterion "==Developer"


      As of a few days ago, this script step reliably crashes FileMaker. Here's what's surprising to me:


      Searching for "Developer" works, with no crashes.

      Searching for "=Developer" works, with no crashes.

      Searching the same table/field for "==Developer" crashes FileMaker reliably, even when I do it manually (rather than by running my script).


      This suggests to me that the field's index is corrupted in some way that affects an == search differently. Any suggestions?

      I'm going to try deleting the index & then recreating it to see if that helps.



        • 1. Re: Novel crashing behavior, seeking suggestions

          It is possible that the record with “Developer” has nothing to do with the crashing. Possibly its an entirely different record with an invisible character in it.


          I’d try exporting all the data in that field. This may cause the crash so use a copy.


          Open the exported file in BBEdit or some other text editor that allows you to view invisible characters. Search document. §^=(




          BBEdit also has a “Zap Gremlins” function that replaces ‘strange' characters with a bullet. It also has a Compare two documents feature. By zapping gremlins in a copy and comparing to the original you can find invalid characters in the data. Caveat, I don’t know how reliable zapping gremlins is so it may not zap ‘all’ invalid characters.



          FIND ==


          If I Recall Correctly an “==“ search does not use the index. I’m pretty sure that’s why it takes so much longer.


          It is an exact match of all characters in the field in the order in which they are entered, including spaces which are not indexed.

          • 2. Re: Novel crashing behavior, seeking suggestions

            On a backup of your file, run the recover option but only with the option to rebuild the indexes and then try it again.  Also check the recover.log file for any indications of what could be wrong.

            • 3. Re: Novel crashing behavior, seeking suggestions

              Is it crashing as in the application force-quits?  Or does it hang with beach ball?  Does it hang for all users when it hangs for one?


              What v-rev is the 11 Server patched to?

              • 4. Re: Novel crashing behavior, seeking suggestions

                It puts up the Find in Progress dialog, which sits indefinitely. Clicking “Cancel” in that dialog brings the beach ball, also never-ending.


                Just opened the files under FMP and found the crashing behavior gone. Hoping it’s gone too when re-hosted on server…




                • 5. Re: Novel crashing behavior, seeking suggestions



                  As suggested earlier,  I would make a copy of the file and run a recover on it to see if there are any issues.  Doing a search with == on a text field should not crash.  If it does have problems,  consider contacting Winfried Huslik.     http://www.fmdiff.com  He has been able to help a number of people with corruption issues.


                  Good luck


                  • 6. Re: Novel crashing behavior, seeking suggestions

                    Update: problem (apparently) resolved by server reboot.


                    Client discovered, to much chagrin, that his backup schedules had stopped operating some time in the past so he didn't have a recent backup.


                    FMS had _scores_ of inactive client sessions that had accumulated over past three days. Log showed some client sessions correctly timed out due to inactivity during this period, but those that ended in client-side crash were persistent. Due to these "stuck" client sessions, FMS would not shut down fully. After giving FMS 3 hours to attempt to close all DBs, decision was made to force quit it and reboot the server computer. During reboot, DBs were moved to another machine and launched under FM Advanced. All of the recent crash-inducing conditions were repeated and there was no crashing. Recent data entry & revision was confirmed present & looked fine. Routine activities were performed without incident. Files were transferred back to the rebooted server and hosted on restarted FM Server, and then closed & reopened a couple times. After a few days of normal production use, the system appears to be stable and unharmed.


                    UPS log suggests a building power outage my have been the initial cause of our problems. Presumption is that a power outage exceeded the UPS' capacity, leading to a crash of the server computer. Timing of this outage seems to correspond to the beginning of the erratic crashing behavior, which appears to have worsened as the number of stuck/crashed/malingering client sessions grew.


                    Fingers crossed for no lasting damage, as reventing to available backup would entail loss of significant development work. Developer (that's me) will take over responsibility for monitoring the backup process!