Sounds like your file or its indexing may be damaged. Test a recovered copy of the file and see if it shows the same behavior. If the recovery doesn't report any major issues, you can try re-indexing your original file.
You can use Advanced Recovery options to rebuild your file's indexes:
With the file closed, select Recover from the File Menu.
Select "Use advanced Options"
Select only: "Copy File Blocks as-is" and "Rebuild Field Indexes Now".
When you say a recovered copy, do you mean just a backup of the original file?
I did exactly what you said, and once complete i got a message saying:
Recover build a new database w/out detecting any problems. However, since the data block, shema, and structure were not fully scanned and rebuilt, there could still be problems in the new database. It would be safest to copy only the most recent work from the recovered file into a backup copy of the original file, instead of using the recovered file going forward. Better results may be obtained by using recover to rebuild the data blocks, schema, and structure.
File blocks: copied as is
Schema: not scanned
Structure: not scanned
Field indexes: rebuilt
When i tested the new file, the indexing was still off (showing 102 of 103 records when there are only 102 records in the layout).
What else can i try?
Try doing the recover without specifying any advanced options. That was my first suggestion. I only suggested the re-indexing if the initial recover reported few or no problems found.
Ok, did that. Now i get the following message:
Warning: problems were detected while recovering the database. Please review the Recover.log file to see where problems were found and their severity. 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.
file blocks: scanned and rebuilt 3441 blocks, dropped 0 invalid data blocks.
schema: scanned fields and tables, 0 items modified
structure: scanned; 3 items modified.
field indexes: rebuilt.
This time, it worked and the indexes are correct (the layout now shows 102 of 102 records).
However its telling me not to use the recovered file. What does that mean? How to i get this corrected on the original file? I don't understand what to take from the Recover.log. Is this a major problem?
It means that the recover process may not have fixed everything that was wrong with the file. It's best practice never to use a recovered file unless you have no other choice. If you have an older back up copy of the file, recover it and see if you get the same error message. If you can find a copy that does not have this problem, you can use save a copy as... with the clone option to get an empty copy of your file, then import all the data from your original recovered copy.
If you can't find such a back up copy, then your choices are less attractive. You can use the recovered file and hope everything is functional or you can rebuild your file a piece at a time by importing tables, scripts and by copy/pasting layouts and values lists. (Even worse, the relationships must be recreated manually.) All with frequent recover actions to make sure you don't import or paste the corruption from your original file into the new one.
Oh yes, before we panic too much here, let's try one more thing first:
Open a copy of your original file and enter layout mode. On each layout in your file, do this:
Select all objects
Choose Ungroup, Say yes to all the warnings about ungrouping buttons. (This is just for a test so the fact that you've disabled all your buttons won't be a problem, we'll just discard this copy after testing anyway.)
Now recover this file and see if you get the same warning. If you don't then the first recovered file is much more likely to be OK to use.
There's a recover bug in FileMaker that will tell you that there's a problem and that the file shouldn't be used when several objects are grouped that have hadd different alignments specified.
For More Information see: FMPA 10: group graphic + align = corrupt file?
This is one of many acknowledged bugs that can be found in the Known Bug List here in the Report an Issue section of the forum.
It can also be downloaded as a database file from: http://www.4shared.com/file/8orL8apk/FMP_Bugs.html
Ok, did that. It fixed the indexing however i did get the same error message again.
"fixed the indexing"????
If you ungroup all the objects in your database and still get the "don't use" message after recovering, you should either find and use an undamaged back up copy or rebuild your file. There's just no way to tell what the recover operation did or didn't do to the recovered file that might affect it's stability and/or function.
Recover's first priority is to restore the tables to a state where the data can be "rescued" by importing it into an undamaged copy of the file. It's second priority is to try to restore the file's correct structure and function. Think of your data as passengers trapped in a wrecked car and recover as the "jaws of life" being used to rescue them. It should get them out if they can be saved, but it may trash your original file design just like the "jaws" may rip the wrecked car apart in order to rescue the people.
i'm sorry, meaning it was now showing 102 of 102 records, not 102 of 103 records when there were only 102 records.
HOWEVER, i just went back into my current original file that i use everyday and now by some miracle its back to normal, showing 102 of 102 records. How is that possible? Just earlier today it was showing 102 of 103 when there were only 102 records???
I just went back into my 'backup' file which had the error. I was sorting the records by a date field in the layout. When i unsorted the records and then resorted the records, it fixed the problem. Do you know anything about sorting records and running into this type of problem? Is my file still damaged?
It's hard to say. That really suggests that there was a problem with one or more indexes, but your index rebuild didn't seem to correct the problem.
You might monitor the file for a few days and see if the problem recurs.
There is a third party utility you can acquire, FMDiff, that claims to do a more in depth scan of your file's integrity. You might acquire that utility and see what it reports.