Last night I ran the file that is reporting the 8461 error through FMDiff 3 and it came back with no errors.

I had already run a FileMaker Server schedule with Verify on, and there were no email notification errors (indicating that the block structure was OK). Just to double check the block structure, last night I ran a manual menu > File > Recover... > Check Consistency button, and the blocks were reported as being OK again.

When I am worried about a file or set of files I run the following 4 tests:

Error 8461 generally occurs if (1) a record being recovered has data that looks like it is from a field or repetition that doesn't exist or no longer exists, or (2) the text in a field is bad; either unterminated or Unicode that can't be properly expanded.

OK, we most likely have data that does not have corresponding enclosing structure, in the form of a FieldID or possibly a FieldID+Repetition or maybey we know the FieldID+Repetition and the text/data is bad.

Is there a way to tell which record (by way of the under-the-hood RecordID) the data should be part of?

Allow me to define the terms of my question...

A FileMaker table has Records and Fields. The intersection of a Record and a Field would be a Cell (using the language of the FileMaker AppleScript dictionary)As entity–relationship diagram (ERD): Record -< Cell >- Field

Is data stored in the FileMaker file by record? (That would be my guess.)

I can imagine cases of FileMaker data corruption where the under the hood RecordID of the data is known. In those cases, it would be useful to return the under the hood RecordID in the recovery.log.

The 8461 error does not return the under-the-hood RecordID. Might be a good enhancement to the recovery.log (if possible).

I am seeing 79 lines with the error message: “Deleted invalid field data, ID or repetition invalid”Does that mean that there are 79 records that have the issue? Does it mean something else?

Would the error message that we are seeing be contiguous RecordIDs, or records in the same 4K block that, due to the adding and deleting of data, would likely be non-contiguous?

> Is there a way to tell which record (by way of the under-the-hood RecordID) the data should be part of?

Not currently. There are too many factors. Once a new record is committed, the data for each field is assigned a RecordID. If for some reason, the commit doesn't update properly, the 8461 error could be attributed to all the fields for one record. If a field is deleted, and not all references to that field are properly updated, the 8461 could be attributed to the one field across multiple records.

> Is data stored in the FileMaker file by record?

Yes. Each piece of data contains a tableID, recordID and fieldID.

> Does that mean that there are 79 records that have the issue? Does it mean something else?

As mentioned above, it could be 79 records, 79 fields, or some combination.

> Would the error message that we are seeing be contiguous RecordIDs, or records in the same 4K block that,

> due to the adding and deleting of data, would likely be non-contiguous?

Very doubtful it would be the same 4K block. If there was damage to a block, the operating system would override and display a message.

> Would an export reveal which records have bad data?

> (Looking for the easiest way to locate the bad records)

Again, doubtful as the ID's would not match up to an existing field or record. However, I would export the data before Recover, export after Recover, and then compare the two files.

Since you can open the original file, export all of the data to text files.

Open an older backup file, and save a clone (copy with no records). Run a Recover on the cloned file and see if there are any errors. If so, see what kind of errors. Then, import the the text files into the appropriate tables.