>>>>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