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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
Links for the Day
- Mac of the Day: Power Mac 7500, introduced 1995.08.08. This workhorse introduced a new desktop case and CPU daughter cards.
- Support Low End Mac
- World Book Encyclopedia 2012 DVD, Tommy Thomas, Reviews, 2013.03.05. "You may be asking yourself, in an age of Wikipedia and instant information, is World Book still relevant?"
- Vintage Computer Festival SouthEast, April 20-21, 2013, Simon Royal, Mac Spectrum, 2013.02.25. Old Apple gear and old PCs.
- iMessage: The Ultimate Messaging Service?, Simon Royal, Mac Spectrum, 2013.02.21. In most ways, Apple's iMessage is far superior to BlackBerry Messenger.
- More links in our archive.
- Best Mac mini Deals
- Best 13" MacBook Pro Deals
- Best Intel iMac Deals
- Best iPod touch Deals
- Best iPhone Deals
- Best iPod nano Deals
- Best iPod classic Deals
- Best Apple TV Prices
- More deals in our archive.
Go to the Troubleshooting Your Mac index.
Low End Mac Reader Specials
Cult of Mac
Shrine of Apple
The Mac Observer
Accelerate Your Mac
The Vintage Mac Museum
Mac Driver Museum
System 6 Heaven
System 7 Today
the pickle's Low-End Mac FAQ