George,

>>Hi George
>>
>>I understand how it can occur, and how to fix it. But difficult to fix when there is no warning of the problem, and that is my main point. Once VFP finds a problem, it appears to simply ignore it.
>>
>>I suspect the issue goes back to VFP3, and the problem hasn't really been looked at since then. Tanks for your comment.
>>
>Geoff,
>
>The problem, as I see it is this: If VFP throws an error in these cases, then the table doesn't open and fixing the problem becomes more complex. OTOH, if it doesn't, it would seem to me to be less of a problem. All you'd have to do is calculate what the size of the table should be (using HEADER(), RECCOUNT(), RECSIZE()) and then compare it to the actual size on the disk. If they don't match, then you know there's a problem, and fixing it becomes simple.
>
>From my POV, this then puts the process in the area of file maintenance. I believe that it's a good idea to periodically PACK tables and re-build their indexes in order to reduce the problems of memo and index bloat.

So if the problem arises near the start of the day, and one relies on "file maintenance" to 'auto-correct' the problem, then how does one 'auto-recover' the data that was added through the day?

Surely VFP could throw a warning message with Retry, Ignore, Fail on EACH write after the problem occurs. That would get people's attention yet let PACK still operate on it.
If this has indeed been the situation since VFP5 then I'd say we have been short-changed on the issue, and by a long shot!

One can only hope forcefully that something will be done to address this in the first SP for VFP7.

Jim