there is not much information...
in general: FileMaker handles several sort criteria fine - therefore, chances are good that it's Your file (damage in some way)
Try rebuilding the index, create a clone and test with new entered data, create a compressed copy, repair the database (a copy!)
the relevant information about a crash, helping forum members to start some guesswork, does not come from your description of what you were doing and what you think. It comes from concrete crash reports generated upon crash by the application (in your case: Filemaker) that failed. Please submit a crash report and let people chew on it.
Hi, thanks, not sure how to generate that report in Filemaker Pro Advanced 15 for Windows. Where do I find it please?
Before dealing with crash reports, do this simple test:
Recover the file and see if the recovered copy crashes. If it doesn't, we can choose best option for what to do next.
I have tried a recovery and it found nothing wrong. But the recovered file has the same problem.
So I am very interested in what is the next step please?
If you have a lot of back up copies, see if any of your older copies do not have this issue.
I have tried some early backups.
The further back I go the more stable they seem to get, but so far they are all crashing after I sort both the tables, and then go back to the first table.
Another thing that is happening is that a few pdfs in containers, which used to show an image of the pdf, now show a pdf icon and the file name instead. One only of them starts <No disk space:[THEN THE FILENAME].
Is that a clue as to what might be happening?
I have now found the only backup that does not crash. It does not have sort order fields, only date fields, so that does tend to point the finger at the sort order fields, but I don't know why that would be.
Always seemed to be crashing around a set of doc records which need secondary sorting (as all the same date) and where I had a few issues getting FM to make a thumbnail of one of them (though finally succeeded). Decided to assume that I have a corrupt pdf and cleared a load of them, then replaced (btw all pdfs stored in "external" storage on same drive/sub-directory).
Since then have re-sorted with primary and secondary on both tables and seems quite robust. I have had less crashes, about 2 crashes out of every 10 openings using a copy of the latest file.
But FM will not retain the secondary sort on the docs table, even though the Keep records in sorted order box is checked and even though it is the latest sort. When I close and open again that sort, which ought to be retained, is not retained. It is just sorted by the primary date sort. Meanwhile the events table retains its primary and secondary sort. Reinstating the docs secondary sort and switching back and forth from events and back to docs layouts does not crash FM as it did before every time.
Still don't know why docs won't retain secondary sort between closing and reopening (whereas events will).
Since the above it has crashed once on opening but on reopening it did not crash and seemed robust, but still only retaining the primary date sort (with events retaining both date and secondary sort order sort).
BTW earlier on in the process (before clearing a load of pdfs) I repaired FM - didn't make any difference.
When I close and open again that sort, which ought to be retained, is not retained.
If your file is hosted on a server, sort orders are NOT retained from one session to another. That's not what "keep records in sorted order" does. It keeps the in sorted order in the same session even if you edit the value of a field that is part of the current sort order. A record can literally "jump" from one location to another within the found set after you edit suc a field.
What you describe suggests problems that don't really have much to do with sorting so much as with container fields and layouts. Corrupted layouts, BTW, often are not discovered/corrected by recover and sometimes simply have to be replaced with a new layout that does not contain any layout objects from the original layout. (In other words, don't copy and paste stuff from the damaged layout to the new...)
Thanks for that clarification on retained sorts. I am not on a server. All on one PC.
Corrupted layout - that is a useful tip. I will replace the layout(s) if this problem continues, as the next step in the fixing it process.
So far so good. No more crashes after an overnight lull in proceedings. Making frequent backups to preserve the underlying data.
Many thanks again for your prompt words of support and sharing knowledge as always.
Here's the latest.
In accordance with your suggestion I created a new documents layout.
The first thing I did was add a container field for the document image. I did this (as you suggested) without copying from the previous layout.
At first it was fine.
But as soon as I made the container field interactive and saved, the image of course appeared, but FM then crashed.
So maybe the problem is with interaction between FM and Adobe Acrobat. Both are fully up-to-date. Running Acrobat Pro DC.
Is there any history of Acrobat not playing nicely with FM and/or any possible fixes that anyone is aware of?