Troubleshooting FileMaker Pro

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.

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.

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.

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.

1. Immediately shut down the affected systems. Run Norton or whatever other utilities are available.
2. Clone the damaged database.
3. Use FileMaker Pro's recover command to recover the cloned database.
4. Export data from old database.
5. Import data into the clone.
6. Save the recovered database as a compressed copy.
7. 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.
8. 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.