If you follow the practice of tracking your changes over time, this is possible but still may involve significant effort. This might mean having to manually recreate those changes. To address functionality loss, you need to re-deploy all of the changes made since the backup file was created.
This data and functionality loss can be overcome, but not easily. if you revert to last month's backup, you will lose whatever schema, script, and layout changes you made to the file since then). if you revert to yesterday's backup, you will lose all of today's data) and even functionality loss (e.g. It's natural to resist this, because reverting to a backup involves loss – data loss (e.g. The second option is best practice: revert to the most recent backup prior to the crash. File recovery may even end up removing solution elements like layout objects or record data in an attempt to fix the file corruption. There is no guarantee that recovering a file will remove the underlying database corruption. In fact, it's quite possible that it will correct the problem enough to make it possible to open the file but leave the root cause of the problem in place, unbeknownst to you. However, it is NOT the recommended option.
Many FileMaker administrators choose the first option, because it is the quickest way to get up-and-running. Recover the file and continue using it – not recommended!.Database may be damaged use the Recover command in FileMaker Pro 16. At this point, FileMaker Server sent out another notification email: When I began my work the next day, I closed the file in the FileMaker Server admin console and then tried reopening it, but it wouldn't open. Since it was Sunday, we agreed that I would work on addressing the issue the next day towards the end of the work shift. I checked in with my client, and he reported that users were still able to use the system. 05:00:20.654 -0600 Error 664 FMS Schedule "Weekly" completed, but consistency check failed on backups of one or more databases.05:00:20.639 -0600 Error 640 FMS Consistency check failed on backup of database "FMDB".The following two notification emails were sent out: The schedule reported that the database failed a consistency check.
The file opened without any errors at that time.Ī few days later, FileMaker Server ran a weekly backup with verification enabled. Progressive backups had been turned on, so I replaced the database with a progressive backup from 11:44 am – right before the crash.
I checked the Windows Server system and event logs to pinpoint the time of the server crash.
It said the database was damaged and could not be opened.īelow is the full notification that was sent. I learned about the outage about an hour later, thanks to a 12:40 pm FileMaker Server email notification. My client's server crashed on Tuesday, April 17th at 11:45 am. Error 242 Database could not be opened may be damaged What follows is an account of how the new Data Migration Tool made it possible for me to quickly address a database corruption issue for one of our clients. This is exactly what happened to me not too long ago. However, if you find yourself in a situation where you have to recover from a damaged file, you will suddenly develop a strong appreciation for the existence of this new tool. The second use case will probably not garner as much notice. Please see my colleague Matt Hintz's post for a detailed examination of this use case. The first use case is likely to receive the most attention.