Iain:
A couple issues with file recoveries:
1) When you use the Recover procedures, Filemaker attempts to rebuild
damaged file structures, data, index structures, and layouts.
Unfortunately, sometimes it does this incorrectly. The current
conventional wisdom from the Filemaker community is to NOT use or
rely on Filemaker's RECOVER functions. The preferred option to ensure
your data's integrity is to go back to your most recent backup and
start from there (you do have a most recent backup don't you ;-)
The second preferred option after crashing is to recover the files,
then immediately export/import the data to a "clean" clone of your
database collection (which you have previously saved somewhere safe
after you made your last set of file modifications) to make sure that
incipient problems caused by recovery don't come back and bite you
later.
Although FilemakerPro may report successful file recovery, in many
cases it cannot do a complete, successful recovery and you may never
know the extent of the damage to your files and data.
To make matters worse, the effects of a bad recovery may not be
evident for days/weeks/months after the fact, making it difficult to
maintain a high level of confidence in data integrity after a crash.
We are in the process of re-writing our recommendations for
recovering trashed ebase files to reflect this new wisdom and will
make an announcement on it's availability in the near future.
2) After you re-launch a "recovered" database, Filemaker still has to
rebuild the field indexes the first time you launch them. Your
initial launch time will depend a great deal on how badly your
collection of databases crashed, the amount of data you have in them,
and whether or not you have multi-user options turned on. Once the
indexes have been rebuilt (and you indeed have experienced no file
corruption as a result of the crash), your initial launches should be
significantly faster.
bob
>The story so far.....
>Computer crashes, some files are damaged and need to be recovered
>All files recovered successfully
>
>On startup of ebase.102 - launches names_.102 and requests password.
>Password entered
>ebase.102 comes to the front
>Ebase.102 then I assume a script in searches network for a long time
>(2-5min) before finding what appears to be the next file in the open
>sequence, setup_.102
>Password is then requested again by setup_.102
>Setup_.102 opens
>Open sequence stops
>To open the rest of the db we must bring name_.102 to the front which opens
>the other related files.
>
>Does anyone have an idea on how to fix this or what the cause may be.
>
>How can I check the scripts in ebase.102 to see if the problem is that file
>- it's passworded so scripts are not accessable.
>
>Thanks
>
>
>iain
>
>
>_____________________________________
>Iain Staines
>JKM Productions
>Toronto Canada
>v. 416.531.7872
>c. 416.885.9750
>e. [EMAIL PROTECTED]
--
-----------------------------------------------------------------------------
Bob Schmitt, TechRocks
38 South Last Chance Gulch - Suite 2A Helena MT 59601-5029
Voice: 406.442.3687 Email: [EMAIL PROTECTED]
eFax: 520.832.1047 Web: http://www.techrocks.org
----------------------------------------------------------------------------
ebase� - Free relationship management software for nonprofits
http://www.ebase.org
-----------------------------------------------------------------------------
Gravity can be your friend.
