I just ran into a problem where a Find (for all records with a null value) would find one "ghost" record (so there were N+1 records listed). The status display would show "Found: 11892, Total:11891".

I recovered the file and it seem to have fixed that issue, but this it the first time this has happened, and I recently updated from FMSA7v4 to FMSA8v2.

Anyone else see this problem? Is it a problem in 8v2? Seems like a deadly / nasty bug to me...

I've seen this happen, in FM5.5

Re-indexing will fix it, in any version

Recover does re-build all indexes, but recover is NOT recommended for routine file maintenance (even in FM8. See FM8 "Help")

FM8v2 was supposed to fix index bugs ... stay tuned

Edited February 7, 200619 yr by Guest

Can't stressed enough: do NOT recover the file to solve something like this. Simply go to the indexed field, turn indexing off. Exit the define database window, go back in and turn indexing back on.

Can't stressed enough: do NOT recover the file to solve something like this. Simply go to the indexed field, turn indexing off. Exit the define database window, go back in and turn indexing back on.

To be honest, neither method is very comforting -- although I agree that under FM5/6, using a recovered file is not a good idea, I'm not so sure that this advice holds true under FM 7 / 8.

I'm curious if anyone here has any first-hand evidence of the sort of "creeping / hidden corruption" problem under FM7/8? If not, I'm wondering if perhaps "preventative recovery" might be wise under some cases in FM7/8.

Specifically had I recovered & optimized my file during my upgrade from FM7 to FM8, it's possible that the damaged field index would have been fixed, and I wouldn't have run into this problem in the first place.

I'm not stating that this is my belief, but I am beginning to wonder whether the old mantra "never use a recovered file" which was arguably true under FM5/6 may no longer "be operative" under FM8.

Thoughts?

There was some discussion when 8 was released that led many to believe that recovery was now safe. But if you read the FMI documentation on it (in the Knowledge Base) it clearly states that it is not. The mechanism has changed from 5/6 to 8 but it will still strip out *anything* it thinks is suspect, whether it is or not. Recovery remains a tool to get data out of a bad file, not a file maintenance tool. But if anyone wants to use it as such, what they certainly would need to do after a recovery is run a full side-by-side comparison of the file (with some diffing tool) to see if anything was changed.

As to the index corruption: it's a well documented 8.0v1 bug. Nasty. But easily fixed by turning indexing on and off.