Jump to content
Claris Engage 2025 - March 25-26 Austin Texas ×

This topic is 8066 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Posted

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

Posted

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..

Posted

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

Posted

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.

Posted

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.

Posted

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

This topic is 8066 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.