Recovery

[Gambler]

The "Recovery" command seems to be a hidden or at least not well documented or talked about. My understanding is that Recovery is used to repair corrupted indexes. Is that correct?

When using Recovery, does it also pack the tables?

What generally causes an index corruption in FM?

How can one avoid this (what are some of the "gotchas")?

Any tips or suggestions about the Recovery program. I created a Recovery command that a user can run from a shortcut. It recovers all data files. Seems to work fine, but I'm concerned that users get messages that "file is damaged and needs to be recovered". This seems to occur more than I would expect (once a week or so).

I'd appreiate your comments and suggestions. Thank you.

Gambler

[Vaughan]

The Recover command is used to recover DATA from corrupted files. It recovers data at the expense of structure: that is, scripts and layouts will be deleted if necessary to preserve the data.

All of which means you should never put a recovered file back into production. You use the recoverd file as the data source for importing into a known-good empty copy of the database. (Don't forget to reset the auto-entered serial numbers.)

This implies that you should always have known-good copies of your databases to hand.

To fix corrupted indexes, go into define fields and turn the indexing off. Exit define fields, then go back in and turn indexing on again.

Then update everybody to FMP 8.0v2 or later (and FMS to 8.0v2 or later as well).

[gdurniak]

see my post here:

http://masdevelopment.com:3455/1/57?view=print

Recover was designed to remove "bad" structure from files. The problem is, Recover will not tell you when things are removed

yes, recover is not well documented

greg

[Gambler]

Okay. I guess I'm still not following this process. When I test the Recovery process it makes a new copy of the file "data.fmp" and renames the bad copy as "data fmp.old" and the data is then moved from old (bad file) to the new duplicate file. Is that not correct?

How does one know if the "structure" is removed from the new file??

[Gambler]

I thought this was an index corruption issue, but you are saying that is not so. So if it's not indexes that are being corrupted, what in your opinion, are the reasons that files get corrupted?

I'd like to know so that I can figure out a better solution to fixing them when it happens and of course a way to STOP it from happening.

Thanks

Gambler

[gdurniak]

Q How does one know if the "structure" is removed from the new file??

A After using Recover, FileMaker recommends that you carefully examine the recovered file, to insure that everything is intact

Q I thought this was an index corruption issue ...

A To re-index your files, export all data to a "merge" text file, then re-import into a clone, using matching field names. OR, go into define fields, turn indexing off (for each field), then turn indexing back on

to STOP index corruption, FileMaker recommends upgrading from FM8v1 to FM8v2. This was a known bug

[Gambler]

This is one area where FM came up short.

FM should have taken the separation model much further. FM should have considered abandoning the unified file system. Had they done this, then index corruption and/or data file corruption would have been significantly reduced if not eliminated.

The one FM issue that troubles me the most is that for either upgrades and/or file, or index corruptions, one is relying too much on importing/exporting the data. As an FM newbie, I can envision the potential problems of what happens when a computer (or server) hangs or crashes during one of these data import/export processes to recover from a corrupted file and/or a corrupted index. I'm very surprised that FM developers haven't SCREAMED loudly for a better method to address these issues.

Importing/Exporting data to solve these types of problems seems very out-dated, especially given how many other things FM does right.

Gambler

[Vaughan]

Gambler, the issues you raise are good and your concerns are real. However, it's part of the balance.

FMP's integrated data and interface files make design and implementation very, very simple. The compromise is slightly less convenient updates for completed solutions etc. But in the main, this isn't a problem for FMP's target market who tend to be owner-developers (if I can coin a phrase) who are usually both developer and end-user. The convenience far outweighs the disadvantages.

On the other hand, FMP is usually very stable. Hosting files in FM Server improves the stablity and performance even more to the point where the need to recover files is practically zero in a production environment (unless something goes wrong like power failure or human error, or the file size limit is reached).

The biggest cause of problems for FMP files has always been running them off shared network volumes instead of the local hard disk. This is a guarantee of data corruption in the long term. I've seen simple systems so badly set up that the users think that weekly recovers are the norm -- these are usually on a shared network volume. Yet significantly more complex solutions running in FMS with dozens of simultaneous users have never, ever had to be recovered even after years of being in production.

The Recover command is a last resort, not a maintenance tool. It is used to get data out of damaged files so it can be put into known-good copies of the system.

[Lee Smith]

Hi Vaughan,

Well Said.

Lee

[Gambler]

Vaughn

Thank you for the clarification. As with everything, there are trade offs. This is just another one must learn to accept and deal with.

As I tell everyone, there are no "PERFECT" programs, just perfect programmers.

[gdurniak]

To Gambler:

1. the "trade off" is cost. I was told by FileMaker staff that it would be too expensive to improve FileMaker's utilities

2. FileMaker's utilities (e.g. Recover) are still at about version 4, while the product has moved to v8

3. please "scream" for us. Contact FileMaker