Recovered files going back online

[Matt Revenaugh]

I've seen posted here everyone fears about putting a recovered files back
online. Evidently, the recover does not always make a good file. So, the
best way to insure a pristine file is to import the recovered data into a
known good file.

Well, here is MY predicament. I don't know if I have a known good file. I've
had to recover a few times (before I knew of this problem) and I don't think
I have a copy that has not been recovered at some point.

Can I "Save a Copy As..." a clone with no records, then import? Or do I
still run the risk of propagating the potential problems?

Is there any way to tell if I have problems? Right now I have a server that
has a memory aneurism. It is a Win-NT box running FMU 6.0. There is a slow
memory leak that takes about a week to finally run the OS out of available
memory. If I reboot once a week, everything is hunky-dory. If not, then the
box crashes hard and I have had to recover the main transactions database.
It's a big file, about 200,000+ records.

I don't know why FileMaker, Inc has burdened us with a flawed recovery
process. I realize that the process recovers data before structure. But if
there are nothing skipped in the recovery, and no other errors reported,
then the user should be able to assume that the file is pristine. Not find
out from his peers that all along there is a potential for hidden problems.

Any help or suggestions is much appreciated.

Thanks,

Matt Revenaugh

[Howard Schlossberg]

I'm not so sure it's a flawed recovery process as a misnamed one. For
the reasons you note, the 'Recover' command is confusingly misnamed. It
should be something more like 'recover data' or 'amputate to save what
you can'.

Most databases will be corrupt after a crash. But since most other
databases have separate data and structure to start, only the
ever-changing data risks getting corrupted anyhow. Big boys like Oracle
have a way of reverting because they keep a history of every transaction
and can, in effect, re-create themselves from the last known good point.
Other databases have utilities that will recover the data only.

More bad wording from FileMaker's recovery process: When FileMaker says
the recovery process found nothing skipped or damaged, it means to say
there is nothing it noticed. But all it takes is one missing bit in a
string of layout info to make the layout flaky during some process. As
an example, how can FileMaker know if there is a bit missing from a
graphic or other layout object. What the program *should* say after
recovery is "revert to a clean backup or use at your own risk".

The recovery process in FMP6 is much better at cleaning up then was
FMP5, which was much better than FMP4, etc. And I think it is safe to
say that the 'next' version of FMP will be even better in this regard --
some have even said 'uncorruptible', though I'll believe it when I see it.

To answer your real question, saving as a clone and importing into that
clone won't in and of itself make things right again, unless the only
corruption was something in the data. If the corruption is in a layout
or script or security or field definition or anything else, then saving
as a clone won't generally clean that up. In situations like yours,
where clean backups are unavailable, knowing it is bad practice, where I
have explained the risks and alternatives to the client...I will
typically do a recovery, make a clone of the recovered file, and then
recover the clone. Sometimes I've seen this help a little. I will then
go through every layout and test it in every mode, go through all my
scripts, the field definitions, value lists, etc, and make sure I see
nothing funny. But even with all that, there is no telling whether or
not corruption exists and might rear its ugly head one day in some
unknown way.



Matt Revenaugh wrote:

> I've seen posted here everyone fears about putting a recovered files back
> online. Evidently, the recover does not always make a good file. So, the
> best way to insure a pristine file is to import the recovered data into a
> known good file.
>
> Well, here is MY predicament. I don't know if I have a known good file. I've
> had to recover a few times (before I knew of this problem) and I don't think
> I have a copy that has not been recovered at some point.
>
> Can I "Save a Copy As..." a clone with no records, then import? Or do I
> still run the risk of propagating the potential problems?
>
> Is there any way to tell if I have problems? Right now I have a server that
> has a memory aneurism. It is a Win-NT box running FMU 6.0. There is a slow
> memory leak that takes about a week to finally run the OS out of available
> memory. If I reboot once a week, everything is hunky-dory. If not, then the
> box crashes hard and I have had to recover the main transactions database.
> It's a big file, about 200,000+ records.
>
> I don't know why FileMaker, Inc has burdened us with a flawed recovery
> process. I realize that the process recovers data before structure. But if
> there are nothing skipped in the recovery, and no other errors reported,
> then the user should be able to assume that the file is pristine. Not find
> out from his peers that all along there is a potential for hidden problems.
>
> Any help or suggestions is much appreciated.
>
> Thanks,
>
> Matt Revenaugh
>

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg (818) 883-2846
FM Pro Solutions Los Angeles, California
Associate Member, FileMaker Solutions Alliance