WEIRD.... Recovery Process MAGIC

[Sam5271]

I have been trying to fix a larg complex database, that I have been building for 5 years (74 tables, up to a 120 fields each). and somehow, seems to be unstable after I moved to Vista and FM9.

Here is what happens.

After I do a File Recovery, it appears that FM 9, which creates a "Recovered Library" Table, and a "Recovered Blob" Container Field, comes up with about 42 records each time. and after about 100 trial of Recovery, after manipulating/deleting tables and fields, I discovered that these recovered Records, are some how container fields, that I have deleted in the past, and FM is now recreating them.

For instance, if I have a Repeating Container Field (Global), and I delete it today. When I do a recovery FM9 seems to create records with each seperate container repetetion.

Does anyone have info, on what FM9 does when creating this Recovery Library, and its blob.

Deleting theses Recovered Records, does NOT seem to prevent it from happening again (when you do a recovery to the Recovered file).

So Any insigh into this is highly appreciated. Also; I have read a lot that one should not use a recovered file, and you should make every attempt to use files that have not been through a recovery process.

By the way, saving a Compact Copy; has in use in this situation. tried it, and it did not change a thing.

Thanks for the help

Edited September 9, 2007 by Guest

[bruceR]

But why are you doing this in the first place? Why run the recover command at all, especially since you seem to be generating problems for yourself? Did you run Save Compacted in FM8.5, NOT FM9, before opening in FM9?

[Ender]

Also; I have read a lot that one should not use a recovered file, and you should make every attempt to use files that have not been through a recovery process.

BINGO! That's the recommendation.

[Sam5271]

Well, this happened by accident, where I was no longer able to go into layout mode, without FM crashing. So When I did a recovery, I discovered this mess.... Then I thought, there must be some corruption somewhere in my databse (Especially that I was getting in the Dialog Box

the number of field definitions that had to be recreated 1).

I wanted to make sure my database are not corrupt. I needed to find the problem, so I can avoid nightmares in the future.... IF it happens that you are building such complex database on a corrupt file structre.... It is going to be a disaster sooner or later. I need to maintain integrety.

[LaRetta]

... I need to maintain integrety.

You accomplish this by:

1) Keeping a design copy aside; one which has NEVER crashed or even burped improperly.

2) While designing, never keep a file which has closed improperly (never, ever). And this means never walk away from your box with the design open. Because if you crash and you come back to your system, you may forget your design was open and you may not notice the scanning message upon reopen (sometimes it is very fast) but it could be damaged anyway.

3) Never keep a solution which has crashed while served - run recover to save the data then export the data and reimport into your backup design (which has never crashed; see #1 above).

4) Periodically, Save a Copy As (Compacted); do not use the File Maintenance tools.

Now ... you may not inherit a solution which you can guarantee has never crashed. And you may not have a pristine empty clone set aside. You may inherit a solution which has crashed repeatedly before you even came to work there. If so, re-design from scratch as soon as you can and, until then, back up frequently and pray often.

LaRetta

[gdurniak]

As reported at DevCon 2006, FM8.5 Recover has a new step, that detects "stranded" (no longer used) library data (often images), and creates a new table, with one container field, and records that point to the stranded data. The appearance of this "Recovered Blob", by itself, is NOT an indication of corruption, since Library data can get "stranded", and is now cleaned up

see my post here

http://nyfmp.org/1/57

greg

[GC GYM]

Is this correct? We should not use the Filemaker's File Maintenance tools, Compact & Optimize? I've been doing this weekly to my file thinking it was a good thing? Yikes!

[LaRetta]

You would think something called Developer Maintenance Tools WOULD be a good thing and COULD be trusted, but no. And one would think its failure should be emblazoned across their website to protect Developers and businesses, but NO; it is left for people to stumble across randomly. DO NOT use the maintenance tools. They move clusters around and, if you experience a problem in the middle, you trash your file. And it seems FileMaker has known about this for quite some time.

As for corrupt files, all told, I would bet FileMaker Developers and businesses using FileMaker have lost hundreds of thousands of hours trusting Recover then having to rebuild anyway or even in researching the PROPER way to handle these issues. Save As Compacted seems to fix many problems but even still ... if a file crashes while being served (and not being accessed through Citrix only), I STILL think it is proper to retire the file and properly import the data into a new clean clone, particularly if you are continuing to develop on it.

I remain hopeful that they will take this problem seriously.

Edited November 20, 2008 by Guest

[GC GYM]

Thanks for the tips. I have a large served file that has had to be recovered twice in 2 years. After recovery it seemed to be normal again so I kept going with it.

Sounds like I definitely need to start rebuilding it from scratch.

In the meantime should I save a compacted copy and then use that instead as the working file?

Thanks, Phil

PS I just deleted the 'Recovered Library' table, was that wise?

Edited November 20, 2008 by Guest

[LaRetta]

In the meantime should I save a compacted copy and then use that instead as the working file?

If portions of your file were sacrificed during a Recover, it can't be retrieved now anyway. But Save As Compacted is always a good thing (from my understandings of it).

PS I just deleted the 'Recovered Library' table, was that wise?

I do not know the answer; maybe others can chime in. I just performed some quick searches here, in FM Help and Tech Info and find no reference to it specifically. But that doesn't mean information doesn't exist! I would assume this is a down-and-dirty dump of anything FM finds which might be important but it would need to be viewed and handled manually anyway. If you see nothing of importance in it, you should be able to delete it. But that is all a guess - too bad this information isn't treated like a First Aid Kit (with HIGH importance), residing where every FM User can access it easily and instantly in case of problems!

Edited November 21, 2008 by Guest

[GC GYM]

Many thanks for your assistance LaRetta.

-)