> Try using the recover function built into filemaker client. This is
> the action i'd normally take if it is telling me that a database is
> damaged, it can recover the file for you and will advise if there are
> further issues. You won't need a user name or password to do this.
And this is the problem with taking advice from strangers on the 'net.
An additional caution here is that you must, after using the Recover
command, NEVER continue to develop on a file which has shown damage.
Recover is intended to get data out into a non-crashed clone of the
file, which you have hopefully kept squirrelled away for just this
situation. It does not in any way repair a file or return it to health.
Recover, further, examines the file for damage, and any object it finds
which does not meet its inbuilt "complete and proper" standards, it
will delete. So scripts or script steps, layout or layout objects,
field definitions, entire tables, areas of the relationship graph, etc,
will simply disappear from the file with no warning.
So in that nice long complicated script where you carefully specify the
layout and found set before performing "Delete Found Records"? Well,
let's just say Murphy will ensure the Delete All stays, but the
preliminary steps won't, and you'll be deleting a whole table, perhaps
even the wrong table. :/
If you do not have functional cloned backups of your structure, tsk.
You'll eventually end up reconstructing the whole file, as damage of
this sort, particularly if you're running Recover repeatedly, will grow
and spread. Sooner or later the whole file will pitch.
Oh, and that "3rd party app" recommended to get a password? It doesn't
crack the password, it writes over the hash string with a new hash
string for a known password. So if you think it wise to write data into
a FM file in the sensitive security area with third party apps, go
ahead. Personally, I would expect this to cause even more damage down
the road.

Signature
Lynn Allen
--
www.semiotics.com
Member Filemaker Business Alliance
Long Beach, CA