Do you get the same results if you disconnect all users and stop the server to draw a copy of the file?
If you make a Recover of the original file, what does the recover.log say?
Open the recovered file once and close it again (without changing anything).
Then compare the recovered file to the original.
FMDiff does not compare DATA.
Export the data to a tab delimited text file and compare the record count of the original file to the line count of the export.
Are the records and fields containing a question mark existent in the export and are they valid data?
Server copy is fine. ( eg no ? )
If I recover the file that had the questions, it says everything is fine - EXCEPT all the indexes are 'different'.
When I compare the two files, with FMDiff - ( the recovered and the fms backup before it was recovered ) the only difference is that it says it was recovered and it removed a font. - Lucida Grande and the record change count for the table was incremented one.
The original fmsbackup file had EVERY row of data all questions. It says the same # of records as the recovered one and the server one.
BUT the all questions will NOT export data. I tried text, and merge formats. The merge gives me 145734 rows of data ( can tell because of the comma between the null field values. ) the db itself says 145768. so the export is 'missing' 34 records.
Since all the records had questions, and all the records after a compressed copy showed good data.
Made a compressed copy of the server file and put that file back into production. - Making an FMS backup of that file, now acts normally.
I have had file corruption issues on a file, and it would show one or a few records as ? the dreaded phantom index records, this was at least someonewhat different since EVERY field in EVERY record was all ? ( but when I created a new record it showed up fine )
My best guess, is that one or more indexes got corrupt. I base that on the recover saying that the indexes were different after recovery. I filled the file originally with 145k records by doing a merge export of the old table and importing that to the new table ( created in a new file with Robot2 which recreates the fields using the DDR def AND internal filmaker creation order )
Still curious how it acted fine on the server, yet had file corruption on the backup.
What do you mean with "the indexes are 'different'"? Who says so? The recover.log or FMDiff?
If it is FMDiff, I suspect you did not open the recovered file once and closed it again before you used FMDiff, as Recover removes the index language of all fields.
I further suppose these 34 records never really existed, they just had their ID bit set due to an error. The number of records FileMaker shows includes the so called phantom records, while the exported records provide the real count.
From what you describe I suggest NOT to a file produced by Robot2 directly, but make a compacted copy of it first and use this.
I'm glad you could solve the problem for now. Its hard to say what caused this. Maybe you make a new install of FMS after performing a hard disk check.
Sorry.. The recover Log says they are different.
You said the 34 records are likley phantoms BUT I am not sure BECAUSE after I did the compaction on the file, then did an export I get the 145768 count......
Yes I am going to always do a compressed copy if I use the robot, even though its just as if you were a really really fast typist... Regardless I think cloning them before they go live would be prudent.
A new FMS is going to be tough. Maybe on Thanksgiving ;-). We go around the clock week days and most of the day on Sat and Sun...
Thanks for walking through this one with me.