Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Numeric overflow issue
Message
General information
Forum:
Visual FoxPro
Category:
Coding, syntax & commands
Miscellaneous
Thread ID:
00588052
Message ID:
00588975
Views:
49
>>>>Chris and Antonio,
>>>>
>>>>Testing for myField = 1/0 returns true on a field with a numeric overflow condition. So this should be a good general solution, or you could SCAN/ENDSCAN and check the condition on each record if necessary:
>>>>
>>>>REPLACE myField with 0 for myField = 1/0
>>>>
>>>>>
>>>>>AFIELDS gives some info, and there are a few more that I cant think of off the top of my head.
>>>>>But by passing the Size and Dec you can use this for more then just a field of an opened database. Making it a general approach.
>>>>>If I was doing something with checking for overflows, I would no doubt do an AFIELDS()
>>>>>then Loop through that, take the size and precision, pass it into the above code, and then replace for myField > maxVal, though it isnt the best way to do the replacement either, replace for locks the entire table if im not mistaken.
>>>>>
>>>
>>>I can not get that condition to be true.
>>>I overflowed a field,
>>>
>>>
>>>?FSize("Num")   => 5
>>>REPLACE Num WITH 99999999999
>>>? Num            => *******
>>>? Num = 1/0      => .F.
>>>
>>
>>Try:
>>
>>
>>? "*" $ TRANSFORM (Num)
>>
>>
>> Jay
>
>Yup that appears to work,
>How much of a performance hit is TRANSFORM though?
>Im not really sure

It depends <g>? I guess on how big the table is.

As you well note, it could be a time-consuming operation on very large tables.

Like others have mentioned in this thread, it's best to trap for this in any way possible to avoid the problem through input masks, etc.

I've run into the problem in a couple places:

1. A division which sometimes had a very small value in the divisor. Testing the result of the calculation against the field size and sticking the maximum value works well.

2. Invalid values in updating a DBC-attached table from another data source through an APPEND FROM. That gives an error.

We used something like this as a stopgap measure until the problem could be remedied:
#DEFINE   BIGGEST_NUMBER   999

REPLACE nNumber WITH SIGN (nNumber) * BIGGEST_NUMBER FOR "*" $ TRANSFORM (nNumber)
To avoid running the REPLACE continually, you could implement a local error handler around data entry or APPEND code and test for the specific error to execute the fix.

I've had enough background in assembler and Pascal to avoid expressions like "1/0" which would throw an exception. But, it's a style thing<g>.


Jay
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform