The last message means exactly what it says. Sufficient serious problems were found during the recover such that there is a significant risk that the recovered file is either still damaged or has been changed so much by the recover that it won't function as expected.
If you have kept a back up file that does not produce this result when you run a recover on the backup file, you should use this copy to save a clone "empty copy" of your file and then import all data from the recovered file into the clone.
Things to keep in mind about Recover:
While Recover almost always detects and fully corrects any problems with your file...
- The recovered copy may behave differently even if recover reports "no problems found".
- Recover does not detect all problems
- Recover doesn't always fix all problems correctly
- Best Practice is to never put a recovered copy back into regular use or development. Instead, replace the damaged file with an undamaged back up copy if this is at all possible. You may have to save a clone of the back up copy and import all data from your recovered copy to get a working copy with the most up to date information possible.
And here's a knowledgebase article that you may find useful: What to do when your file is corrupt (KB5421).
I have successfully found an uncorrupt copy of my database and cloned it. However upon importing my clone is still damaged and unusable. And I'm back to square one. What am I to do next?
Am I expected to re-input nearly 2000 entries manually?
Why does this happen?
What is my guarantee it won't happen again.
Then perhaps your clone is not undamaged after all.
There are no guarantees that this will not happen again. There are no guarantees that any file from any application you use is undamaged and will remain that way.
If you are certain that the clone is truly undamaged, you can try importing subsets of data into different copies of your clone to try and isolate which portion of your imported data is the source of the trouble.