Just to let you know, I've sent this off as an issue to Jim Saunders at Microsoft.

>Can anybody confirm this? I tried it in VFP 7 in different computers and llOtherUser and llThisUser were always .T. in my tests.
>Maybe you increased the field width or inserted one digit value?
>
>If I replace an insert statement with the lines
>
>

>append blank
>replace test with 10
>

>
>a vfp error occurs as expected.
>
>>I'm not sure why you're not getting an error when you try to stuff 10 into a single digit field. I would expect a "Numeric overflow" error, but I don't get an error either. IAC, I do get .F. for both llOtherUser and llThisUser, which is what I'd expect.
>>
>>>I try to use an update conflict logic as described in
>>>
>>>Multi-user and Data Buffering Issues (20K) at
>>>
>>>www.stonefield.com/pub/buffer.zip
>>>
>>>This article recommends to use oldval() and curval() do dedect data changes.
>>>However, in case of field overflow, this code wrongly reports that data
>>>is changed.
>>>In the following sample code, both llOtherUser and llThisUser fields are .T.
>>>How to fix Doug's code ?
>>>Why an VFP error does not occur in this code ? Is this a VFP bug?
>>>
>>>

>>>close all
>>>set multilocks on
>>>create table test ( test n(1) )
>>>* Why an error does not occur on next line ?
>>>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. ?
>>>