Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Fixing Doug Henning update conflict dedection logic
Message
Information générale
Forum:
Visual FoxPro
Catégorie:
Base de données, Tables, Vues, Index et syntaxe SQL
Divers
Thread ID:
00567205
Message ID:
00567237
Vues:
24
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. ?
>>
Andrus
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform