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.
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.
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.
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?
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…
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.
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!