Troubleshooting FileMaker Pro
Dan Knight - August 23, 2000
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.
Troubleshooting Your Mac Articles
- Troubleshooting: What Works, What Doesn't
- Addressing Battery Problems
- Stopping a Bomb at Startup
- Changing Your Startup Drive
- Troubleshooting Claris Emailer
- Troubleshooting FileMaker Pro
- Solving Floppy Disk Problems
- 32-bit Addressing on Older Macs
Go to the Troubleshooting Your Mac index.
Follow Low End Mac on Twitter
Join Low End Mac on Facebook
Favorite Sites
MacSurfer
Cult of Mac
Shrine of Apple
MacInTouch
MyAppleMenu
InfoMac
The Mac Observer
Accelerate Your Mac
RetroMacCast
The Vintage Mac Museum
Deal Brothers
DealMac
Mac2Sell
Mac Driver Museum
JAG's House
System 6 Heaven
System 7 Today
the pickle's Low-End Mac FAQ
Affiliates
Amazon.com
The iTunes Store
PC Connection Express
Macgo Blu-ray Player
Parallels Desktop for Mac
eBay