Hi,
I think primary cause of the problem starts when there is a hardware/software problem and a control character is written to the file, and VFP doesn't pick it up. It causes the following to occur.

1. Sometimes some of the characters to the right of the control character are not saved to the field, but instead are appended to the end of the file, thus causing the header/file size difference error. It must be a buffer overflow error or the like, but it is erratic, sometimes all the characters are appended to the end of the file, sometimes it is only the last three.
2. If you create a cursor from the table the control character somehow screws the cursor causing the error you are seeing.

From personal observations I have found that the problem occurs when the hardware is less than adequate.

>Hi neil,
>
>>This happens if some rubbish i.e. End of File character is added to the end of the file. Just trap for the error condition, append blank record then delete. Then try again.
>
>Well this particular bug in VFP6 should have been fixed in SP5. I'm not sure if this was the case. I'll try to find the backup to invesitgate if this indeed the problem.
>
>However, since I set TABLEVALIDATE TO 0, I'd expect no checking of the problem at all, but yet it does. Stranger, it does check it in one instance, but not in another. Esspecially the problem on the view, since it is refering to a temp file. What could have cause the corruption of a table header of a cursor ??
>
>From your other reply:
>
>I'm aware of the Kb, but this does not seem to fit into my specific problem though.
>
>Walter,
>
>
>
>>>I've got a problem in one of my products, reporting a error 2065: table "mytable" has a file length /record count inconsistency that will not allow this transaction to be committed.
>>>
>>>The table in question is a transaction log table and is involved in other transactions as well. The problem is that it only errors in one certain transaction, while any other transaction still is fine. It really seems like a VFP bug to me, since in both cases there are records appended to "mytable".
>>>
>>>Anyways, I saved the contents, zapped the table, and it seemed fine again. However it still is strange that one occasion it errors on END TRANSACTION and in another it does not, while the code within the transaction is very simular, but involving other tables.
>>>
>>>But, OK, I can live with the fact that if there is a problem in the table it is going to error. I'll just have to repair it.
>>>
>>>However, more serious, I've got the same problem in one occasion where from time to time the problem occurs on a CURSOR (SQL view) rather than on a table (it is refering to a temp table). Since the cursor is made within the same VFP session and stored in a temp file on the local HD and the behaviour has presented on different machines, I highly doubt that this has anything to do with hardware issues, there must be something within VFP itself causing the problem. Unfortunately the behaviour is difficult to reproduce and there certainly is quite a bit going on within the transaction.
>>>
>>>BTW SET TABLEVALIDATE is set to 0
>>>
>>>Anyone with the same experiences. any hint or trick ?
>>>
>>>Walter,