>Jim,
>
>I am not talking here about the situation when entire records are hidden because they were not accounted in the header. If I recall it correctly, versions before VFP6 were sensitive to this corruption. And it is good that MS returned back here.
>But if it is just a piece of one record, then it leads to confusion, it cannot be fixed by existing third party products, and reasonably (I believe)was ignored in the previous versions (including at least DOS 2.5).

Yuri,
I would agree with your "reasonably" if there was certainty that it was only a 'piece' of a record involved. I have my doubts.

Jim

>
>>Hi Yuri,
>>
>>While your repro code undoubtedly presents the problem, we must be sure that people are not confused about HOW this problem arises in real life and it SEVERITY.
>>
>>I think that, in fact, HOW it occurs remains UNKNOWN... I'm sure there would have been a fix if the cause(s) were known.
>>
>>That VFP8 traps this problem and makes it known may be reason itself, alone, to make the upgrade for many many people! The problem sits there undetected and unknown to the user in (at least) VFP6 and VFP7.
>>
>>Since it is known that (VFP6/7) TRANSACTIONS will NOT INSERT/APPEND records when the problem is existant (and possibly such non-transaction commands too) there could be NUMEROUS records LOST without knowledge of the user until much muchj later.
>>
>>The above is why I still encourage anybody who experiences the error in VFP8 to report the conditions in as detailed as possible a manner, in hopes that the collective body of fact developed will help to expose the real source of the problem.
>>
>>cheers
>>
>>>Probably many of you already know or have discovered that VFP8 is more sensitive to "table corruption" than all previous FOxPro versions.
>>>
>>>What I have discovered that one type of corruption seems harmless and is ignored in all previous versions, but in VFP8 it initiates the message "Table ... has became corrupted. The table will need to be repaired before using again." No other details or guidance are given and table cannot be used.
>>>Actually in the situation like this when you can open table in VFP6 or VFP7, you need to append blank and delete it to "fix" the table and be able to use in VFP8.
>>>
>>>I have checked some of the available TAble Fixing tools and discovered that they do not see that the table is corrupted.
>>>
>>>Actually what happens is for some reason the table has a piece of garbage appended to the table end, but this piece has a length less than a full record. So the size of the dbf file (excluded the header) does not indicate additional full record comparing to what is in the header, and Table Fix Tools ignore it (again, I checked only some of them).
>>>
>>>Here is how to reproduce the behavior:
>>>create table tmptab (fld1 c(10))
>>>for ia=1 to 10
>>>insert into tmptab values (padl(ia,10,"0"))
>>>endfor
>>>use
>>>?strtofile(filetostr("tmptab.dbf")+"HELLO", "tmptab.dbf")
>>>
>>>Now the table cannot be used in VFP8, but in VFP6/7.