Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
VFP bugs on numeric field overflow
Message
 
To
16/10/2001 16:05:19
General information
Forum:
Visual FoxPro
Category:
Troubleshooting
Miscellaneous
Thread ID:
00567942
Message ID:
00569510
Views:
29
Andrus,

I think that in this situation you can not lean on oldval/curval checking only, but should also verify that data is not corrupted. If my previous suggestion does not work, then I would try something similar to:

?isdigit(str(eval()))


>To summarize:
>
>In VFP 7 : oldval(), curval(), eval() screen output is same, some comparison determines that values are different
>
>In VFP 6: oldval(), curval(), eval() screen output is different, comparison determines that their values are same.
>
>I tried your suggestion to exclude corrupted data but havent got consistent results in VFP 7.
>
>At record save time, I need to determine are the table fields changed
>by other user to avoid overwriting its changes.
>
>For this, I use code from Doug Hennig error handling paper by scanning all table fields.
>However, in VFP 7, if numeric field is not changed at all but corrupted, this code erroneously
>reports that data was changed by other user and thus prevents current user to save data its changes.
>
>How to fix this ?
>
>
>for lnI = 1 to fcount(m.lAlias)
>  lcField      = field(lnI)
>  llOtherUser  = oldval(lcField)   <> curval(lcField)
>  llThisUser   = evaluate(lcField) <> oldval(lcField)
>  llSameChange = evaluate(lcField) == curval(lcField)
>  do case
>    case llOtherUser and !llThisUser
>    * Another user edited this field but this user didn't, so
>    * discard current changes.
>    * In VFP 7, it occurs also if numeric field is corrupted. Why ?
>.. etc
>
>
>>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
>>>>>
Previous
Reply
Map
View

Click here to load this message in the networking platform