Steve,

it may very well that VFP has become smarter by the years, and that I have not noticed. This overflow used to be a biiiig problem in the first versions of VFP which supported SQL SELECT. Kilofox has many pages describing why this happens, and how to work around it, as far as I remember. However, in VFP9 we will at last have the CAST function so that we can decide the format of the result of the SELECT statements.

>Tore,
>
>I've never seen a problem caused by the multiplication side of this situation. Just did some testing with values, that when multiplied, far exceeded the width of either of the two fields. Used small numbers for the first record, so its result for the first record would be small. VFP handled it just fine.
>
>I just don't see the point in complicating matters by returning a result that is not the correct answer, and then having to adjust those numbers back down somewhere else.
>
>>Better safe than sorry. Since I had no idea about the max value of a.price*a.catchweight, I wanted to be on the safe side. I was sure that Gil understood the picture, and adjusted the multiplicator, if necessary.
>>
>>>>I tried to change my line, but since I already had received a feedback, I could not update.
>>>
>>>Sorry about that :)
>>>
>>>>This was ment to be my second try:

>>>>select 1000000.000*iif(a.split_in="Y",a.price*a.catchweight,0)as T

>>>
>>>Why do you want an answer that is 1000000 times too large, when it is not necessary?
>>>
>>>>VFP tries to guess the width of the field, and if the first record is 0, then the width will not be big enough.
>>>>
>>>
>>>It not really a "guess"; it uses the width of the first record. "Guess" would imply that we have no control over the situation. No big deal, though.