Jump to content

  •  

UPGRADE DEADLINE - SEPTEMBER 26, 2014!
FileMaker Inc. has a deadline for users of version 10,11, 12 as Individual box or volume licenses (with expired maintenance).
If you don't renew your maintenance and upgrade to FMP 13 you will no longer be eligible to upgrade, at the discount pricing.

Volume Licensing upgrade pricing for FileMaker Pro 13, FileMaker Pro 13 Advanced and FileMaker Server 13 will be discontinued.
Individual upgrade pricing for FileMaker Pro 13 and FileMaker Pro 13 Advanced will increase after September 26, 2014.
As of 27-September-2014, FileMaker 10 products will no longer be available for purchase or support.

http://help.filemaker.com/app/answers/detail/a_id/13865


Photo
MAC

Recover Question



  • Please log in to reply
7 replies to this topic

#1 Rick Whitelaw  Time Saver

Rick Whitelaw
  • Members
  • 698 posts
  • LocationToronto, Canada
  • FM Application:13 Advance
  • Platform:Mac OS X Lion
  • Skill Level:Intermediate
  • Membership:TechNet
  • Time Online: 22d 6h 56m 4s

Posted 19 December 2013 - 10:28 AM

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.


  • 0

#2 LaRetta   Lifelong FM Student

LaRetta
  • Members
  • 9,783 posts
  • LocationOregon
  • FM Application:13 Advance
  • Platform:Mac OS X Mavericks
  • Time Online: 216d 9h 15m 7s

Posted 19 December 2013 - 12:11 PM

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.


  • 0
Each assumption is an educated guess, a likely condition or event, presumed known and true in the absence of absolute certainty.

#3 Rick Whitelaw  Time Saver

Rick Whitelaw
  • Members
  • 698 posts
  • LocationToronto, Canada
  • FM Application:13 Advance
  • Platform:Mac OS X Lion
  • Skill Level:Intermediate
  • Membership:TechNet
  • Time Online: 22d 6h 56m 4s

Posted 19 December 2013 - 01:28 PM

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.


  • 0

#4 gdurniak  journeyman

gdurniak
  • Members
  • 236 posts
  • FM Application:8
  • Time Online: 1d 14h 55m 23s

Posted 24 July 2014 - 04:14 AM

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


  • 0
Gregory Durniak
Bayside, NY
www.fileshoppe.com

#5 LaRetta   Lifelong FM Student

LaRetta
  • Members
  • 9,783 posts
  • LocationOregon
  • FM Application:13 Advance
  • Platform:Mac OS X Mavericks
  • Time Online: 216d 9h 15m 7s

Posted 24 July 2014 - 07:27 AM

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.


  • 0
Each assumption is an educated guess, a likely condition or event, presumed known and true in the absence of absolute certainty.

#6 gdurniak  journeyman

gdurniak
  • Members
  • 236 posts
  • FM Application:8
  • Time Online: 1d 14h 55m 23s

Posted 09 September 2014 - 09:10 AM

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


  • 0
Gregory Durniak
Bayside, NY
www.fileshoppe.com

#7 LaRetta   Lifelong FM Student

LaRetta
  • Members
  • 9,783 posts
  • LocationOregon
  • FM Application:13 Advance
  • Platform:Mac OS X Mavericks
  • Time Online: 216d 9h 15m 7s

Posted 09 September 2014 - 03:44 PM

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.


  • 0
Each assumption is an educated guess, a likely condition or event, presumed known and true in the absence of absolute certainty.

#8 Rick Whitelaw  Time Saver

Rick Whitelaw
  • Members
  • 698 posts
  • LocationToronto, Canada
  • FM Application:13 Advance
  • Platform:Mac OS X Lion
  • Skill Level:Intermediate
  • Membership:TechNet
  • Time Online: 22d 6h 56m 4s

Posted 09 September 2014 - 04:39 PM

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





FMForum Advertisers