Database Reference
In-Depth Information
▪
Copy logical structure (same as Compacted Copy)
. This choice creates an optimized
file that takes up less space on your hard drive and operates more efficiently. It's a good
choice for keeping a file in shape
before
corruption shows up, but it doesn't check for
structural damage.
▪
Scan blocks and rebuild file (drop invalid blocks)
. The heavy hitter of the bunch, this
process reads every piece of data (those are the “blocks” it refers to) and removes those
that appear to be damaged. It's a blunt instrument designed to salvage data even at the
cost of structure like layouts and scripts. Use this only when a file won't open normally.
Figure 13-32. When good databases misbehave, the Advanced Recover Options are your instru-
ments of discipline. Still, file maintenance can be an exercise in patience. If your database runs into
many hundreds or thousands of megabytes, recovery can take hours.
UP TO SPEED: FILE RECOVERED. NOW WHAT?
The Recover command has reanimated your recalcitrant database, but at what cost? Upon comple-
tion of a recovery, FileMaker places a file called Recover.log in the same directory as the recovered
file. Inside you'll find painstaking documentation of every step taken in the recovery process. It's
here where you may learn a bit more about what went wrong. Scan through Recover.log's Error
column. If you see anything but a zero, a problem was encountered on that step.
Regardless of what went wrong, putting the recovered file into service is not recommended. Your
best bet for a happy, healthy database is to pull a backup copy of the database that was saved before
it corrupted. Make a clone of the backup (
Saving a Clone of Your Database
)
then import the data
from the recovered copy into the clone. This process combines your most current salvagable data
with your cleanest database structure.
