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?