There's an (old) good read from back in the day from sixfriedrice:
This has been my defacto understanding of what causes "corruption" and how to deal with it, including fallbacks to backups. A lot of people don't have a core understanding of what the different recovery and maintenance options do in FileMaker, which leads to confusion and differing opinions depending on who you talk to.
IMHO, for schema/layout corruption during a migration, there will never be anything "better" than rebuilding your interface and schema from scratch. It gives you the opportunity to modernize a solution and convert to something like a data separation model to make future development easier. Since based on your screenshot that's where the corruption was (schema, not in the block scan), this would be the best option.
If you're diligent and have a good backup (and understanding client), then I don't see any reason why your client couldn't use the converted copy for a month while you build out a new file. The migration to your new file should be relatively easy since it's mostly just data transfer.
Agreed with Mike.
I would go back through the backups to see if there is a point where the damage happened.
Regardless of the option chosen, the deployment absolutely needs to be scrutinized to see if there are any clues as to WHY the file got damaged.
Like Wim I am an advocate for Root Cause Analysis.
Corruption is a symptom.
Root cause is defining the factors in the system (not FM itself) that caused or contributed to the production of the symptom.
Fixing the corrupted file is only part of the battle.
If you don't find and mitigate the cause(s) then its going to happen again.
As you probably figured out the Conversion process "creates" a new file. It uses the schema from the original file but does not actually copy the information over. The result is the new file is cleaned up and the 'damage' is left out of the new file.
However, what was the damage? It may be gone but if it took out something important then it cannot be forgotten.
I recommend you review the whole file; every field definition, script step, calculation, Custom Function, and Layout object, for something missing. For example a layout object could be missing the Tool-Tip. Or it could be missing Custom Formatting. A field could be missing it's Auto Enter Calc. or be missing completely missing.
Try: save as clone, revcover and re-import data.
It's my understanding that you should never use a file in production that has been run through Recover. Since it can potentially drop bits from the file.
Always do the recover with a copy...
check out the log' from the recover (as mentioned earlier) - there are errors reported in the log that are not really errors (the final dialog tells You that You should not use the file anymore..), some errors were reported because of (ie) non-identical maxima/minima coordinates of grouped objects (the maxima/minima of the individual objects won't match minima/maxima of the group) - ungrouping and grouping-again will resolve that..
The process that creates a .fmp12 version of a .fp7 file should create new objects (also mentioned here) - and chances are good that the file is ok after conversion (run the recover on a copy of the V14 file). Yes - Winfried Huslik knows a lot about the structure of FM files, it's a good tip to ask him. And yes - one's never sure about that recover (no manual, mixed content (the error column shows informational entries as well), etc...
As you probably know, my "discussion" is here:
The "Warning" Dialog can often be ignored
e.g. if your "errors" are just a few calculations, try editing ( or deleting ) them, and run recover again. You may be surprised
This whole issue of "I'm not sure" is just an embarrassment. FileMaker needs to explain what all the cryptic Recover output really means
> Discussion: What would you do and what are your arguments?
The discussion here is not about what you think they should/shouldn't be doing with it. I would request that we try to focus on the issue at hand and not let this thread spiral into misery.
This thread represents an insanely positive learning experience for everyone that uses FM. It would be nice to keep it positive.
( Cont'd )
Your Warning Dialog says "5 Items Modified", yet the Log you show only has 3
It would pay to attach the entire Recover Log to your Post
> The file is damaged and it is recommended that we get data out of it and do not use it.
I went through something similar once. I learned from FileMaker engineers that corruption can build slowly over time and you don't even notice anything until one day the file just starts to act up while in use, or maybe during a regular server reboot the file refuses to activate. In one case of a bad file, we could sometimes get the file to run on the client when off the server, and after hours and hours of playing, for some bizarre reason, we found that the data in one particular record was making the file crash on the server. Something in that block was broken. We were able to reenter the data into a new record and it worked fine, but we really learned how to keep backups for a while.
Winfried...looks like your reply was victim of the Jive-Email bug. Your reply is blank.