|
Other World Computing: 9.1GB Apple ROM SCSIs only $175.00, Sonnet G3 starting at $126.50, G3/400mhz only $197! Check Out These Deals and More at OWC! Only $5 for FedEx delivery too. Click Here!
|
Disk Problems? Gone! Get the BEST disk protection software available for your Mac!
|
Troubleshooting FileMaker ProDan Knight
August 23, 2000Recent 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. PreventionServing DatabasesMac 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 ModificationAll 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 InformationIf 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 IssuesLarge 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 DatabasesFileMaker 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 TrackingLogging ChangesSeveral 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 ChangesAnother 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 RecoveryBackupThank 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 RecoverySeveral 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 FieldsFileMaker 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.
<back to Troubleshooting Your
Mac>
Low End
Mac established April 7, 1997. This page,
the entire Low End Mac site, and all subsites of
<http://lowendmac.com/> copyright ©1997-2000 by
Dan
Knight unless otherwise noted. All rights
reserved.
LINK
POLICY: This site allows and encourages
links to any public page, so long as the linked page does not appear
within a frame that prevents bookmarking the linked page.
Low End
Mac is an independent publication and has
not been authorized, sponsored, or otherwise approved by Apple
Computer, Inc. Apple, the Apple logo, Macintosh, and iMac are
registered trademarks of Apple Computer, Inc. Additional company and
product names may be trademarks or registered trademarks of the
individual companies and are hereby acknowledged.
LinkExchange
Member | 
