Recent problems with some of our
FileMaker Pro databases have
raised a number of issues that must be addressed. Most of the
following information was gleaned from members of the Mac Managers email
list.
Several Mac Managers commented that they have never lost data
except as the result of programmer error or user error. That being
the case, the following guidelines should be helpful.
Prevention
Serving Databases
Mac Managers roundly condemned us for allowing users to run
databases from the file server. This is something FileMaker
strongly discourages. Shared databases should either be run from
the user's hard drive or on FileMaker Pro
Server. They should never
be run from a file server.
In fact, every time you launch a shared database from the file
server, it pops up a dialog box suggesting you copy the file to
your hard drive instead of running it off the server. This is not
only an issue of stability, but of server and database
performance.
The first step in fighting database corruption is getting all
FileMaker Pro databases off the file server and onto user hard
drives or FileMaker Pro Server. Ideally, all shared databases would
be served on FileMaker Pro Server, but that may not be practical.
How each shared database is handled will depend on how heavily it
is shared.
Managed Modification
All shared databases should have limited access. Further, it is
wise to restrict the number of users who can change which fields in
accessible databases. This is an issue for the FileMaker
programmer.
Further, all programming changes should be recorded in a
log.
Saving Information
If a user modifies a field and the database crashes without the
cursor moving out of the changed field, FileMaker Pro does not
record the change. In fact, other recent changes may also be lost.
Users should always tab to another field or click outside the field
to make sure the modification is saved. I doubt this has been a
problem here, but it could be a small contributor to our problems,
since if a computer locks up while the user is modifying a field,
that change will not take place.
One suggestion from Mac Managers is adding a "save" button to
each form, which would get users in the habit of clicking outside
the data field after making changes.
Cache Issues
Large disk caches can prevent data from being saved in a timely
manner. The disk cache in the Memory control panel should normally
be set to 2,048K.
Duplicate Databases
FileMaker Pro is smart, but not smart enough to know that two
databases with the same name may not be the same database. If there
are two or more databases with the same name, FileMaker Pro will
use the first one it finds. Thus, it is imperative that every
database on the network have a unique name.
Data Tracking
Logging Changes
Several Mac Managers suggested using scripts to track every
change made to a database. This is beyond my expertise, but should
be something a FileMaker programmer could implement.
Tracking Changes
Another suggestion was tracking the date, time, and user making
the last change to any database record. This is probably something
that a FileMaker programmer could add to automatically record who
is modifying each record.
Data Recovery
Backup
Thank goodness for backup. We use QuicKeys to shut down
FileMaker Pro Server at about 1:00 a.m., just before backup. This
assures that databases are not active for accurate backup. We have
the ability to recover every database from any weekday over the
past eight or nine years.
File Recovery
Several Mac Managers outlined the most effective method of
recovering a damaged database.
- Immediately shut down the affected systems. Run Norton or
whatever other utilities are available.
- Clone the damaged database.
- Use FileMaker Pro's recover command to recover the cloned
database.
- Export data from old database.
- Import data into the clone.
- Save the recovered database as a compressed copy.
- Make sure the new clone is renamed to match the original file.
Be sure to keep the original under a different name just in
case.
- Relaunch the database.
Calculated Fields
FileMaker Pro calculates fields once and works with the stored
results unless you change the calculation for that field or modify
the data it is calculated from. Thus, a damaged database may have
incorrect results in calculated fields. The solution, if file
recovery doesn't solve the problem, is to force recalculation on
these fields. The easiest way to do this is to add zero to numeric
fields and "" (nothing between quotes) to text fields.
