Sounds like this issue:
For More Information see: Phantom Record, damaged file message, Recover can't detect a problem
This is one of many acknowledged bugs that can be found in the Known Bug List thread here in the Report an Issue section of the forum.
It can also be downloaded as a database file from: https://www.dropbox.com/s/jt09b82i0xijbu3/FMP%20Bugs.zip
That's consistent with your recover results. Recover rebuilds all field indexes without attempting to analyze them for problems. And rebuilding the indexes usually corrects this issue.
It's possible to use advanced recover techniques to only rebuild the indexes and not make any other changes to your file.
what happens when You do a 'Find' in one of the fields? Happened here as well, brand new FM12 database, hosted on FMS -> backup copied from the backup folder, then question marks every where (normal backup, not the incemental new type). Never had this before. Hosted DB without any problems, never crashed, never repaired.
Seems to be a different issue,
I just tried a "find" on it now and it shows the data. When I close and re-open it's working as expected.
I wonder if sorting records would also have made the question marks go away.
I'm speculating here, but one of the indexing options for a field is: "none: turn indexing on as needed". So performig a find can change the indexing for a field and so can sorting records...Either might be just enough of a "nudge" to the system to correct the issue and cause the data to display properly.
Sorting also fixed the issue.
Again, the server hosted file was fine. Using the local backup file was not. Something hosed somewhere, be it client or server.
can some kind soul from FMI chime in here? Since -at least here- the db-file was FM12 only and hosted on FMS, I'm afraid that there might be a bug, somewhere...
the version on the FMS closes and reopens frequenty (backups) - and there, everything is (seems to be) ok
Thank you for the post.
Have you run recover on the file to check for damage?
Things to keep in mind about Recover:
While Recover almost always detects and fully corrects any problems with your file...
1. The recovered copy may behave differently even if recover reports "no problems found".
2. Recover does not detect all problems
3. Recover doesn't always fix all problems correctly
4. 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.
What to do when your file is corrupt (Answer ID 5421).
If you are able to replicate this behavior outside of the current database file, using a new database file built in FileMaker Pro 12 or one of the starter solutions, please let me know.