Hi Jim !
1. Thanks for that change. Somebody can be dissapointed but I am sure that
database product should not open bad database file without issuing an error.
In FoxProDOS it works in that way - I do not know why it was changed in VFP.
Maybe because in that way one can use PACK command to repair corrupted table.
If it is true maybe better woould be use new commad something like REPAIR or USE ... REPAIR or SET AUTOREPAIR ON

2. Did you make in VFP8 any changes to make FLUSH command works as it should.
- i mean realy write changes to disk not only to OS buffers (if hard disk buffering is off it seems to be possible) ?



>
>We made a change in VFP8 to address the issue described in http://support.microsoft.com/support/kb/articles/q293/6/38.asp. Records added in a transaction can be lost when the table is corrupt in such a way that the header record count disagrees with the actual number of records in the table.
>
>Now we check at USE whether the header record count and actual number of records in the table agree, and give the error if the table is corrupted, i.e. the two don't match.
>
>I suspect this is what you are seeing. You should be able to clear the problem by PACKing the table in VFP7. Let us know if the PACK does not clear the error, as we may be looking at something else.
>
>Thread 580276 contains some additional info about this corruption issue.
>
>If the problem happens at BROWSE rather than USE, then I would suspect an index problem rather than table corruption.
>
>If this is the case, you could do a Ctrl+C on the error dialog (this works in VFP7 and later) to copy the exact error text, and post it back here.