I'm doing a bit of summer work on a database for one of the schools I work with, and since I have a rare window with the database all to myself I ran a recover to "Clean it up". It hasn't had any problems, and the log doesn't show any problems except for:
2025-07-02 09:20:43.108 -0400 Map Academy Compacted.fmp12 8495 WARNING: problems were detected while recovering the database. The recovered file should NOT be used going forward; copy only the most recent work from it into a backup copy of the original file.
From what I'm finding online that's not ideal, but also not something I should panic about. If I need to do anything "Major" this would be the month to do it since teachers come back mid-August. My gut says just ignore it, but let me know if there are any other tools or methods to better understand the "problems" that were detected. Is there a more detailed log or another tool? I found a thread from way back when that @WimDecorte had a tool he was working on, not sure if that would help me or not.
Have you tried recovering the recovered file to see if the message persists?
Yeah. Recover => Recover => Compress => Recover
Probably overkill but I figured I'd try it.
In that case I’m afraid it will be a case of trial and error. We’ve found all sorts that cause a file to report corruption, scripts, fonts and layout images for example.
We’d start with a ‘blunder-bus’ approach and delete half the tables and half the layouts in a copy and the other half in a 2nd copy, then recover each to find whether the problem is in one file or the other. If one reports no problem and the other does, then focus on that and repeat on that file. If you’re lucky(!) you may be able to narrow the problem down to a specific object or item, remove it and do the same on the master file and try again.
When file corruption is reported our mind immediately goes to structure and probably panic, when in fact the issue is often very solvable.
Good luck and we wish you well.
Andy
1 Like
This is super helpful, thank you. I maybe should have figured out this myself, but for some reason the idea of doing this hadn't dawned on me.
I wonder if FMPerception from Proof+Geist could help ? I never used it on a corrupt file, but maybe you could get a hint at what is wrong. There is a 14 day trial.
Were there any report of issues from the users before the schools closed ? Any hint from your users may help.
Wish you the best of luck. Finding the latest backup that is Ok would tell you when the corruption took place.
Did you check the server for failed components, like HDD, SDD, Power Supply ?
I went back 6 months and it has the same problem... so it's not new. I have FMPerception and it seems to work normally. shrug
We had a couple of crashes over the past couple of years, but nothing that repeated.
The DDR or the XML output that FMPerception relies on will give advice about missing objects, e.g., "<field missing>" as it describes the database but it doesn't do diagnostics. A missing object is not corruption.
1 Like
Hum, I guess Claris people are those who have THE knowledge to pinpoint what is wrong. Does Claris offer to analyse a corrupt file to provide more hints ?
No, it's not a service they offer.
If you identify a bug in supported software versions and they can't reproduce it they will often ask for a copy of the file so that they can investigate but that's a different thing.
It would be great if they provided more information than they do. The current feedback isn't much.
1 Like
By "clean it up" do you mean the default advanced recovery settings? There will be a Recover.log file in the destination directory, and if you got that message at the end, it will have at least one error logged.
Interpreting the logs can be a bit tricky as there are some things that will create false positives. But some even non-error level messages can indicate real problems.