Hi aleksey,

We dicovered a very serious bug with the SET TABLEVALIDATE setting when the argument is set to 8 or higher.

The problem exists in both VFP8SP1 and VFP9, tested on 2 total different Win2K servers.

SET TABLEVALIDATE TO 15
USE s_error
ZAP
USE

USE s_error -->> Bang, corruption error
SET TABLEVALIDATE TO 0
APPEND BLANK
BROWSE NORM

And guess what, I did not end up with one record but as many there were in originally, but it seems that the table was not zapped, but only the records where blanked. It definitely seems that the table header information was NOT FLUSHED TO DISK and not retained in any matter.

Interestingly when I refilled the table with its original content and did

SET TABLEVALIDATE TO 0
USE s_error
ZAP
USE

SET TABLEVALIDATE TO 15
USE s_error 
APPEND BLANK
BROWSE NORM

And everything went fine.

After a more thorough analysis, it seems to go fine also when SET TABLE VALIDATE is set to a number smaller than 8.

So I guess this can be classified as a very serious bug in VFP. The SET TABLEVALIDATE TO 15 setting seems to cause more problems than it solves.

I guess this is the root of the problems we are having at a client where we frequently encounter table corruptions with a SET TABLEVALIDATE TO 15 Setting.

Can you confirm the bug and pass it into the pipeline please ?

Regards,
Walter,