"Never use" is an oversimplification. It's a matter of managing risk to choose the best option. Unless the recover operation advises you not to use the recovered file file, odds are very good that you will have no trouble with the recovered copy. What you are choosing between is an undamaged backup and possibly imperfectly recovered file in most cases so even a small chance of trouble with a recovered copy makes it the less desirable choice.
What this advice typically ignores, however, is that your "undamaged" back up may actually be damaged as well. File damage may not produce an observable issue until multiple back ups have been made. I've seen cases where no one knew the file had a problem until an OS or filemaker was upgraded. In such cases, using a recovered copy may be your best option.
You've indicated that "your back ups aren't always up to snuff"--that does not have to be the case. On a hosted solution, progressive backups should enable you get a back up only minutes old. If developing a non-hosted copy, install OnTimerScript can save a uniquely named copy of your file every 15 minutes.
FMI statement keeps you in the 100% safe zone, but comes at a cost in terms of flexibility. The more flexibility you get, the more safety you loose.
At the risk of being blamed for giving poor advice, if you recover a file and the recovery report says that it only modified a couple calculation fields and zero data blocks loss (you MUST check the recovery.log file) then you should be reasonably safe.
Having a file damaged is like dropping your phone. If you drop it from a 10th floor it's 99.99% sure your phone is gone forever. If you drop it from your table may be it'll get a small scratch but it'll work normally. Now, if you drop your phone from the table a hundred times...
Here are some tips to avoid file recovery:
- Be careful with your files.
- Use the development version of Filemaker Server, let it make many backups for you.
- If you can use a real server, better. If not, at least use a virtual server from Amazon or Azure.
- From time to time perform a recovery just to make sure everything is OK (ditch the recovered file).
- Use some kind of database analysis tool (Base Elements, Inspector or FMPerception).
- Keep track of all your changes BEFORE you make them, i.e.: schedule them. I use Jira to create versions and keep track of what I did on each version. Once I release a version a save a copy of that file in a separate, backed up folder, so I can "roll back" to a previous version if I screw it up.
Being a successful developer it's not just a matter of skill and creativity, it's also about discipline. Being careful with your solutions is an act of discipline.
Hope this helps
1 of 1 people found this helpful
I sense there may be a change of attitude about using a recovered file.
Please see TSGal's last comment on 2016-10-18 in this thread:
"There's a history over the years that recovered files should never be used. However, most of this is based on the results of the Recover. Specifically, if the Recovery says to NOT use, then something in the file has been deleted, rebuilt, etc. You should go back to your original file and save the data. That was the reasoning for my initial post.
However, if the Recovery found no errors, and the Recover.log file doesn't display any errors, then the recovered file is good to use."
All the best and hope to see you in Phoenix,
1 of 1 people found this helpful
If the recovery doesn't find anything wrong then why not use the original file? I would probably compact the file, because cleaning it up is a good thing to do. But there isn't any reason not to use it. Is there?
A recovered file will have all new indexes and a number of other settings in the file will be changed back to "factory spec".
"Recover" has always been a mystery
And for FileMaker to say you "may" be able to fix a layout with Recover does not help
To be fair, since FileMaker 10, Recover can repair certain problems
If you have no recent backup, and the layout in question can not be easily rebuilt, and any "corrupt" objects can not be deleted by hand ( items marked as "changed" in the Log ), then try using the Recovered copy. It "may" work
I have more details here: http://www.fileshoppe.com/recover.htm
> you may be able to repair the layout by recovering the file
I recently had a dev copy of a database, originated in v14, now hosted in v15, go bad. This manifested in all new layouts, whereby they could not be resized vertically or horizontally. FMI confirmed that it was a corruption and recommended a Recover.
The Recover process completed with this message, "Recover built a new database without detecting any problems. The new database is safe to use, though you should monitor the results carefully and make sure to keep up-to-date backups of your databases.".
Fortunately, those corrupted layouts regained normal behaviour. In this particular instance, it was more practical to move forward with the Recovered clone than to worry about backups, as the issue had 'lurked' for some time, before being investigated.
If what you say is true, then please report it as a "bug"
Recover should have reported a "Problem", that somehow got fixed
This is why no one trusts "Recover"
> The Recover process completed with this message, "Recover built a new database without detecting any problems"
Fortunately, those corrupted layouts regained normal behavior
Given that FMI already had a clone, and they subsequently recommended that I run a Recover, I'm guessing that the file (and issue) are already being (sensibly) poked and prodded.