mac Recover Question

[Rick Whitelaw]

Hi,

 

     I have a small issue that's been nagging at me for a while. One file in a multi file solution fails Recover. The file functions perfectly. Some years ago when running Recover I started noticing a pattern FM would attempt to recover Table " " then create a new table "Recover". It also created a field "Recover" in two tables. If I open the Recovered file and delete these three items, then run Recover on the copy the file gets a clean bill of health. Even my oldest backups of this file (when it was tiny) show the same problems so I don't have a clean backup. 

     I've never used a Recovered file. Now I'm trying to decide whether to just leave good enough alone and continue with the original file, or trust the clean bill of health of the "Recovered Recovered" file. Any thoughts would be most welcome.

 

Rick.

[LaRetta]

Hi Rick,

 

Sorry to hear about the file.  My sense would be to rebuild it but I also realise that will take some work - you indicated 'when it was small' so I assume it would be a large undertaking now?  

 

Have you experienced any other crashes with it?  If not then maybe I would keep going with it while I planned a complete rebuild, such as 13 would be perfect time.

 

It would be a tough call, for sure.

[Rick Whitelaw]

Hi,

 

No crashes. No problems whatsoever. Consistency check is fine. The supposed corruption has been there for years. I'm sorely tempted to use the double recovered file.

[gdurniak]

Sorry for the late reply

 

Your "problem" is covered here:  http://fileshoppe.com/recover.htm

 

The addition of a "recover' table is a new "cleanup" step, that does not by itself mean the file is damaged

 

greg

[LaRetta]

The only thing I would question, Greg, is that a Recover normally does *NOT produce this recover table occurrence.  So when it DOES appear, it indicates to me that it has found something (at least) questionable.  And when Recover finds something questionable, it can mark those areas as bad even if they aren't (meaning it takes aggressive action to scrub it and the scrub itself can damage).  And this is why files should not be used after a Recover (even if no Recover Library is produced).

 

I would consider the file damaged if I saw Recover Library table appear.  That does not mean I'd trash the file immediately but it would be high on my list to rebuild it as quickly as possible (immediately if I have good backup).  The same holds true if I see a Recover log appear.  It usually indicates the files was improperly closed and that can damage a file.

 

Now in 13 with Web Direct, a recover log is created when you upload the file (which drives me nuts) so that is the only exception where a recover log wouldn't cause me to dump a file and step back.  Folks seem to forget that the pristine nature of the files in a solution are CRITICAL.  It is very difficult to rebuild a file.  It is very simple to hold oneself to extremely high standards of file protection.  I am a LION not a cat when it comes to protecting files.  Once damaged, they can cause problems until the end of time.

 

Added ---  * you can test whether Recover Library is generated by creating a new file with a few fields, close it then run recover on it.  Really good files do not produce this Recovered Library table occurrence - only files with damage.  At least this is my observation.

[gdurniak]

Again, sorry for the late reply

 

I asked this exact question to FileMaker's Clay Maeckel at DevCon,  and he assured me that "it is not by itself an indication of corruption, since Library data can get "stranded", even in a "healthy" file"

 

He went on to explain that it is very similar to uninstalled Windows Applications,  that leave behind "orphan" DLL's,  that are harmless

 

greg

[LaRetta]

That is good to know, Greg.  But still, if you improperly close a file, it WILL generate the recover table.  And if a file is closed improperly then it DOES indicate that it should be replaced with a good prior copy.

 

So it, by itself, may not indicate corruption but the logic still says that, if you are not sure it is okay, assuming corruption and replacing it is the best strategy.

 

And that is why designing on copies of the original and then moving the functionality into a pristine copy of the master and designing locally as much as possible are still best suggestions.  And seeing the recover library, unless you are SURE it did not close improperly or experience connection drop, should still be treated as trashed.

[Rick Whitelaw]

This is an old thread. A couple of comments . . . The Recover process ALWAYS generates a Recover Log. As far as Recover adding a table "Recover" I have no idea what's up with that. However it does not generate this when running Recover on a Compacted Copy. It will also add fields named "Recover". I believe that rebuilding the tables in which these fields are inserted IN THE ORIGINAL FILE may solve this problem. In my case, Recover inserts this field in two tables. Rebuilding these would be much easier than blindly rebuilding the entire file. I haven't done it though. These fields are created to match data apparently (data that doesn't exist).

My two cents,

Rick.