I'm going from memory here, but I think 2065 is related to TRANSACTIONs and is NOT related to SET TABLEVALIDATE.

There was a very dangerous bug in prior versions (before VFP8) where transaction records would not be saved BUT everything appeared normal and the program continued along its merry way. In other words, data could be lost and you'd only find out about it after the fact, when the user noticed it!!!

The error message does *not* fix the error, but it does now let you know that something is amiss and lets you do something about it (i.e. at least stop and let the user know).

How to remedy the source of the problem is not at all clear... the bug was identified but no reproducability made it unsquashable. I'm sure the VFP Team (what's left of it) would be most pleased to find a situation where it is always reproducible.

I guess what I would do is:
0) Intercept the error
1) ROLLBACK
2) terminate
3) In a fixup prg, open the table with SET TABLEVALIDATE at 0, USE the table,
APPEND BLANK a record, then delete that record. (intention to rewrite the header with the correct values).
4) Let the user try again.

I suppose there's always the possibility that the HD has a flakey spot.
One thing I would do for sure... tell all your users that all hard drives are to have 'write behind cache' DISABLED. Workstations and server.

good luck


good luck

>Is it possible to get error 2065 (Table name has a file length/record count inconsistency) when the setting "Set Tablevalidate To 0" is in place ? I never remember getting this error in vfp7 even when the situation it describes occured, but I have 1 customer who is getting it even thought the Load of the form has the tablevalidate setting in place.