Error ** Decimal number is too large. (536)

Platform: Linux
Version: 10.1B

I have a report summation which the decimal data type doesn't seem to be able to accomodate. Does Progress have a data type larger than "Decimal" ?
 

TomBascom

Curmudgeon
Or perhaps you might provide a bit more details behind "doesn't seem to be able to accomodate". One possibility that springs to mind is that your format mask might simply be too small for the result that you are attempting to display.

Providing the text of the actual error messages that you receive is always helpful.
 
The decimal data type can handle up to 50 digits. I suspect that your summation is faulty.

The figures exceeded 50 digits. We have a package for our clients to use, they don't use the system correctly but refuse to change their practice. For example, they scale up all kind of rates, say, if the rate is 65.1245, it will be scaled up to 651245 in the database. If the amount is 123456.4567, then it will be scaled up to 1234564567. That's why the yearly summation of some figures exceeded 50 digits. We try to entertain all clients and that the use of a larger data type seems convenient.
 

TomBascom

Curmudgeon
I'm having trouble wrapping my head around how that would even work. I get scaling, it's a common enough thing but:

1) Mixing scales like that should just produce garbage.​
2) 50 digits is a *lot* of digits. I'm intensely interested in what could possibly require that kind of (scaled) precision?​
The other "large" data type in Progress is int64. But according to Wikipedia the largest unsigned value for int64 would be 18,446,744,073,709,551,615 which is only 20 digits.

I think your customer is going to have to come to grips with reality and use unscaled numbers.

(I think I remember from college Physics that you can model the entire freaking universe down to the Plank length and you only need pi out to about a dozen digits. Or something like that...)
 
I'm having trouble wrapping my head around how that would even work. I get scaling, it's a common enough thing but:

1) Mixing scales like that should just produce garbage.​
2) 50 digits is a *lot* of digits. I'm intensely interested in what could possibly require that kind of (scaled) precision?​
The other "large" data type in Progress is int64. But according to Wikipedia the largest unsigned value for int64 would be 18,446,744,073,709,551,615 which is only 20 digits.

I think your customer is going to have to come to grips with reality and use unscaled numbers.

(I think I remember from college Physics that you can model the entire freaking universe down to the Plank length and you only need pi out to about a dozen digits. Or something like that...)

You are right. Changing the data type doesn't seem to be the way to go. Thanks very much.
 
Top