It's a known issue. in older versions, the fields of such a "phantom record" often showed question marks.
It's been known to happen due to a damaged index. The record doesn't exist but some part of the indexing system indicates otherwise.
Try the following:
Take a copy of the file and run a recover on it. Use Advanced Recover Options with these options selected:
Copy File Blocks As-Is
Rebuild Field Indexes Now
Check and see if this record still shows in the recovered copy.
If that fails to fix this do a full recover of the file and check that recovered copy.
Things to keep in mind about Recover:
While Recover almost always detects and fully corrects any problems with your file...
- The recovered copy may behave differently even if recover reports "no problems found".
- Recover does not detect all problems
- Recover doesn't always fix all problems correctly
- Best Practice is to never put a recovered copy back into regular use or development. Instead, replace the damaged file with an undamaged back up copy if this is at all possible. You may have to save a clone of the back up copy and import all data from your recovered copy to get a working copy with the most up to date information possible.
And here's a knowledgebase article that you may find useful: What to do when your file is corrupt (KB5421).
Unfortunately I have used a recovered db a while ago, mainly bc it said that it was safe to use. Im going to have to run these checks later in the day when no one is connected to the db, but i will try this on a backup right now.
Now that we are on the subject, Can I or should i delete the tables that are created called "Recovered" or "Recovered Library"?
I'm very surprised that it indicated the recovered file was safe to use if it found such issues. Normally, you are told NOT to use the recovered file when such issues are uncovered during a recover of the file.
And it can sometimes take several tries to successfully delete the table and it's corresponding table occurrences depending on the exact damage thus repaired.
I strongly recommend reverting to a back up copy if you have one that recovers without a report of such issues. You can make a clone of such a back up and import your data into it to get a non damaged file with up to date data.
I just ran a recovery on my backup from last night, it indicated zero problems and said that it is safe to use. The blank or phantom record was not present in the backup tho. So once all the users are done for the day i will grab another backup from today with the phantom record and try your suggestions.
Do you suspect there will be an error during the recovery bc of this phantom record?
If it is due to index problems. The recover will correct the issue, but not detect the problem as recover deletes all indexes and rebuilds the from scratch without trying to analyze indexes for problems. Importing into a clone (empty copy) of the file also rebuilds all indexes so you probably do not need to do both.
It is very tempting to just use the recovered file. Its the only one that is fixed.
I do have a backup that does not contain the phantom record that i could import all the data from the recovered into but its a lot of data. Is there an easy way to import data straight over from one filemaker file to another? or do I have to export to excel and import that way?
If you used the Advanced Recover options that I originally spelled out for rebuilding only the indexes, you can use that recovered file safely. (The recovered file is also likely safe, but it's better not to take chances.)
You can use Import Records to import records in a table of one FileMaker file directly into a table of table in another FileMaker file. There is no need to export first then import from a file of exported data. This can be done manually via Import Records from the File menu or you can set it up as a script. Best approach is probably to take your back up file and save a clone of it using the "save a copy as..." option. Then you can open up the Clone and import records from your recovered file into your clone. Manually, you would do each import from a layout based on the table into which you want to import your records. The other detail to look out for in this process, is to make sure to update the "next serial value" of any fields that auto-enter serial numbers or new records created after the import may get serial numbers that match existing records. This can be done via Manage | Database | Fields manually or this also can be scripted.