>This very problem has been causing me some concern in the last few months.
>
>In the program to demonstrate the problem, the header count is manipulated to corrupt the table, and yes, there is no error.
>
>But I believe that in the past, this would have produced the old 'not a table' error. I also believe that in VFP, the header is now said to be automatically corrected.
>
>To test this, I made a second version of the test prg to reopen the database and the table. It reported the same corruption, so it seems clear that the header is not being fixed. I think that is also demonstrated in the program itself, since the file is reopened. No question of caching in the additional test - I restarted VFP.
>
>In my own experience, I had cases where up to 1000 journal records were not added to the table before the users spotted a problem. Nasty. I did discover that the last journal written in one instance was 1 char short of its correct length. I assumed that the correction routine relied on the assumption that if the header count was incorrect, it relied on the physical length always being correct in terms of the header + n times the record length.
>
>The KB article carries a review date of 31 March, and the problem is still there in VFP7. Isn't it about time this problem was addressed?

Geoff,

One of the problems with xBase tables isn't really a problem with the tables themselves, but rather one caused by the write behind cache (latency), which is not controllable from an application.

Now, as far as I can recall (going back to VFP 5.0) the VFP has never thrown an error when opening a table where the record count in the header doesn't match the physical number of records. AFAIK, the easiest way to correct this discrepency is to open the table exclusively and then PACK it.