Walter,
>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.

I don't think so. In fact, I think the opposite is true - at some point VFP dropped that check and it was only re-instituted (in a way) in VFP8.

>
>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 ??

The 2065 is independent of SET TABLEVALIDATE - specific, as I understand it, to writes within TRANSACTIONS.
I would also seriously doubt that subsequent writes to the same table would actually have happened, given that you have TABLEVALIDATE at 0. My suspicion is that they went off into the ether, never to be seen again.

I don't have a clue as to what might have caused the problem on a CURSOR, but it surely is an interesting situation! This information might assist MS in tracking the problem down (they have yet to get good repro code and maybe this can be isolated to become such).

From many other messages here on this subject (loosely) it seems definitely related to VFP but non-specific in that it can happen on great/poor configurations, only in a few (maybe even only 1) install/use of the same application in many shops, etc.

I think the MSKB #Q293638 is the far more germane article here. The 2065 error is just a trap for the condition, not a fix.

cheers

>
>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,