Thanks, I should have been more clear in my original message. I'm familiar with general Recovery issues & practices; it's this specific error (`creating field ''`) that I'd like to learn more about.
When FileMaker have a corrupt file it almost always create a new table with a new field. Check your tables to see if you have that. If that is the case you have two options
1. Try to find out where the corrupt part is. That could be a object on a layout or a entire layout
2. Send your file to FileMaker and have repair it with a better tool then we have in FMPA.
4 of 4 people found this helpful
The PDF Demystifying FileMaker Pro File Recovery...
...is a good read. See, for example, page 11...which while it does not mention 8474, seems relevant in your case.
Thanks, TonyWhite! Yes, it looks like (based on the doc Demystifying FileMaker Pro File Recovery (Last Updated, March 3, 2009) ) the catalog in question is part of the Relationship Graph, modified as part of Step 4.
Also, thanks for the suggestion to inspect it with FMDiff, beverly. I hadn't thought of that before, but am downloading a copy to try now.
2 of 2 people found this helpful
The way I understand it is that a FileMaker file contains structure and data for fields (and other object types).
Structure and data should match. Data “fits” within structure.
If the recovery process finds data with no structure...it creates structure to contain the data so that it can be recovered/gotten to.
Since the structure was not seen by FileMaker, the name given is not super descriptive.
Just curious, which FileMaker Version, and which OS ?
Did Recover add a Field to any Table ?
It looks like you had something with no name '' ( blank )
At the end of the Log, you should also see "fields created to match record data: 1"
> Rebuilding library catalog '' order list: type
8474 Creating field '' to match record data
- FileMaker Server 126.96.36.1992
- Win Sever 2k8 R2
None of the fields in the database have `null` names, as far as I can tell; nor is there any indication that new fields were actually added to any table. Certainly not on the scale indicated by the trailing Log entries below:
2017-06-22 14:32:59.176 -0400 FAMDealDesk.fmp12 8474 Creating field '' to match record data 2017-06-22 14:32:59.179 -0400 FAMDealDesk.fmp12 8474 Creating field '' to match record data 2017-06-22 14:32:59.182 -0400 FAMDealDesk.fmp12 8474 Creating field '' to match record data 2017-06-22 14:33:13.066 -0400 FAMDealDesk.fmp12 0 Evaluating library (331) 2017-06-22 14:33:18.509 -0400 FAMDealDesk.fmp12 8495 WARNING: problems were detected while recovering the database. The recovered file should NOT be used going forward; copy only the most recent work from it into a backup copy of the original file. 2017-06-22 14:33:18.514 -0400 FAMDealDesk.fmp12 0 Better results may be obtained by using Recover with default options to rebuild the data blocks, schema and structure. 2017-06-22 14:33:18.535 -0400 FAMDealDesk.fmp12 0 Schema: scanned fields and tables; some problems were found... 2017-06-22 14:33:18.537 -0400 FAMDealDesk.fmp12 0 fields created to match record data: 97588 2017-06-22 14:33:18.540 -0400 FAMDealDesk.fmp12 0 field values deleted due to invalid ID or repetition: 0 2017-06-22 14:33:18.544 -0400 FAMDealDesk.fmp12 0 records deleted due to invalid ID: 0 2017-06-22 14:33:18.546 -0400 FAMDealDesk.fmp12 0 Structure: scanned; 1 item(s) modified
Wow ! created 97,588 ( of something )
Based on the Log Message "Better results may be obtained ..." , you might want to do as it suggests, and run Advanced Recover, with both "rebuild" boxes checked ( both schema and structure ), and see what happens
> fields created to match record data: 97588
> Better results may be obtained by using Recover with default options to rebuild the data blocks, schema and structure