Thank you for your post.
Try running a Recover on the file. That is, launch FileMaker Pro, pull down the File menu and select "Recover". Select the database file in question, and let Recover create a new file. FileMaker will do its best to fix the file, although it is not guaranteed to fix all problems. When finished, open the Recovered file. Does this work? If so, then try to find a backup of the original file that opened successfully, and then import the data into the appropriate tables from the recovered file.
Please keep me updated with any progress.
I had not pursued your suggestions (and was ignorant of Recover ...). I now have.
The Compressed Copy worked for about 30 sec, then quit. Subsequent openings now quit on launch.
Similar behavior out of Clones, Duplicates, etc. (Obviously, all of these required multiple attempts to get FM to stay open long enough to even access the File Menu ; )
Recovery Consistency Check found no problems on either the original (or any dupes or Clones). After Recovering, there were no problems reported, but the same behavior is exhibited out of the Recovered File: FM Quits on launch or very soon thereafter.
I'm really at a loss and would welcome further insight. Many thanks in advance, /J.
It may be that your file is damaged in a way that filemaker's recover tool can neither detect nor correct. Got any old backups you can test?
I have had a similar problem on a much larger and more complex database. I have a couple ideas you can try.
Pull a recover on your database and examine the font list recovered (near the top of the recovery log).
If there are any fonts that are listed, but not actually installed in your computer. It will crash. Doesn't matter if those fonts are actually in use in your database, if they have EVER been used in your database, it is still flagged as a font than needs to be available, and FM tries to cache it on opening (and when it cannot, will often crash). You cannot 'clear' this internal list stored in your database file (if there is a way, I'm dying to learn).
If you have fonts listed multiple times you probably have to rebuild the schema and cleanly import your data.
If you are curious as to WHY this might occur, there is a very interesting (if lengthy) read at:
I suffered from duplicate versions of Arial. Probably from one installed by the system, the other from an Office X installation--and I wasn't paying attention.
Less likely, all your fonts are correctly listed in FM, but one of your installed fonts is corrupt; so it FM crashes while caching.
It is a good idea to delete the system fonts cache and let it rebuild itself (particularly if you add or remove any of your installed fonts). Several utilities can help you with that, I used FontExplorer X Pro (they have a nice 30 day trial version).
Indexes. Some of the crashes I've seen seems to be related to indexing. A standard recover default to rebuilding indexes 'now'. Try using the advanced option and select 'later' which deletes the indexes and resets them to a flagged 'index as needed' state. This puts my database back to a working state, tho it eventually will crash again; still trying to work out what part of indexing is causing the crashes to occur.