harryk Posted October 19, 2002 Posted October 19, 2002 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
harryk Posted October 19, 2002 Author Posted October 19, 2002 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..
CG Software LLC Posted October 20, 2002 Posted October 20, 2002 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
Anatoli Posted October 20, 2002 Posted October 20, 2002 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.
CG Software LLC Posted October 20, 2002 Posted October 20, 2002 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
Vaughan Posted October 21, 2002 Posted October 21, 2002 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.
harryk Posted October 23, 2002 Author Posted October 23, 2002 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
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now