Hi Walter,

This is a lot of time ago, but I tried to find something new about this bug and I didn't found anything.

I make some tests here, using VFP9 SP1, and it seems ok.

Could you confirm if this BUG has been fixed?

TIA.



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