>>>>>>Does this work?
>>>>>>

SELECT CAST(VAL(test) AS Currency) AS nBigNumber ;
>>>>>>    FROM cuTest ;
>>>>>>    INTO CURSOR c_temp
>>>>>>SUM nBigNunber TO lnTest
>>>>>>* Or, use a direct SUM() in the SQL SELECT.

>>>>>It gives an error "Currency value out of range".
>>>>I hadn't seen the solution post, but try Double.
>>>
>>>Double does not give an error, but it gives the same wrong calculation as a direct SUM.
>>>Good to know, it's an issue when you have to add bank account numbers to create a checksum for the bank files for instance.
>>
>>Double's issue is that it only has 15 to 16 significant digits of precision. It handles much larger numbers, but always and only with that level of precision.
>>
>>Currency uses the 64-bit signed integer form which allows real integer math in the range of -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807, but with 4 implied decimal places, so:
>>
>>Currency:
>>−922,337,203,685,477.5808
>>+922,337,203,685,477.5807
>>
>>If you need a larger form I can give you a very simple C++ DLL to include in your project which will handle arbitrary bit sizes for floating point or integer.
>
>Thanks, but I am happy with the other solution, using a "manual" calculation with character strings. The good thing is that it works as well in FPW2.6, where the problem initially showed up. Also there is no possible limitation, which is great because now they allow bank account numbers of up to 20 digits.

Hi,

Indeed, this is the best solution, which I have also implified for an IBAN-checker (bankaccount numbers up to 36 digits)

Regards,

Koen