Writing the manual for a solution, I am a bit puzzled by what the developer manual 5.5 states on chapter 5-7:

.quote.

Tell your users what to do once a file has been recovered. Tell them to:

1) recover the damaged solution file

2) open the recovered solution file in the runtime appl

3) Save a compressed copy..

4) Give the compressed file the same name as the original filename

.end of quote.

What I do not understand are two things. Why is step 3 and 4 necessary, and the second thing: why saving compressed..

Hope you follow my non-understanding..thanks in advance.

Harryk

Replying to my own question some days later..

I think the best advice giving to users about files being recovered is to import them again, then see if any errors occur, and if so, going back to the last back-up..

The FM-advice about saving compressed still doesn't make sense to me..

Hi,

I don't know why Filemaker suggests the last two steps either. I tell my users to recover and then import the recovered file into a new copy of the file. This way they don't have to rely on a recovered file for everyday use.

Thomas

RE: I tell my users to recover and then import the recovered file into a new copy of the file.

Just suppose the corruption (weird characters etc.) is in data in one field. That way probably the same corruption will appear in new file.

More secure way is to export data as text -- tab delimited file and import that to clone of file.

I just don't know if that is possible with Runtime.

Yes, that is possible with a runtime. Thank you for the suggestion, I will start recommending it next time a customer has this problem.

Regards,

Thomas

It makes sense when it is realised that the Recover command is intended to onlt recover DATA, not files.

The recovered data should be imported into a clean file. For users with a runtime, getting a clean file might be impossible. The process of compressing a file might also clean up the file's structure.

Don't forget, those instructions were for users not developers.

The disadvantage of using a clone is that in a clone all the graphic data is lost as well as all the globals.

Therefore it might be an idea to provide users always with a 'clean' file that has the necessecary graphic data (and perhaps global information), in which they can import (either FM import or text-based). This in case of emergencies.

> For runtime users, getting a clean file might be impossible.

When? If the filename fits, it will fit in the bounded solution.

Might be that the 'always prevent modification of data' checkbox can spoil things up when it comes to importing, don't think so, but am not sure about that.

Harryk