Yes, it is interesting.
Corrupted data is represented differently in VFP6 and in VFP7.

In VFP6 I see something like this (for Windows NT, for Windows98 it is slightly different):
oldval(lcField) *****.*****
curval(lcField) |*****.*****
evaluate(lcField) x0{******.***

So, they are different in VFP6.


But in VFP7 they look exactly as in the table:
oldval(lcField) *
curval(lcField) *
evaluate(lcField) *

So, they are the same in VFP7.

*---------------------
I do not know how to resolve this issue directly on FoxPro level, but for your particular situation I would use some kind of obvious comparison, like:

?evalute(lcField)>1E10

to see whether it is a valid number.




>Yes.
>
>But new in VFP 7, the oldval() and curval() for corrupted fields are different.
>This makes not possible to save a record if it contains a currupted field
>and remote updating is used.
>Is it possible to get correct values in llOtherUser and llThisUser ?
>
>

>set multilocks on
>create table test ( test n(1) )
>insert into test values (10)
>use in test
>use test
>cursorsetprop( 'buffering', 5 )
>lcField      = field(1)
>llOtherUser  = oldval(lcField)   <> curval(lcField)
>llThisUser   = evaluate(lcField) <> oldval(lcField)
>* Why llOtherUser and llThisUser are both .T. ?
>assert !llOtherUSer
>assert !llThisUSer
>

>
>
>>The same behaviour you can find in at least in FoxPro2.5 for DOS and in VFP6.
>>
>>>I encountered the following two anomalies trying to use VFP 7.
>>>Can you confirm, are they VFP bugs or not.
>>>
>>>Bug 1
>>>VFP Error does not occur if insert command causes overflow
>>>

>>>create table test ( test n(1) )
>>>insert into test values (10)
>>>

>>>
>>>
>>>Bug 2
>>>
>>>In REPLACE, VFP Error occurs, but data is corrupted
>>>
>>>

>>>create table test ( test n(1) )
>>>APPEND BLANK
>>>on error note
>>>* this line produces error but data is corrupted.
>>>REPLACE test WITH 10
>>>on error
>>>SET ASSERTS ON
>>>* this assertion fails.
>>>ASSERT test=0
>>>