At 01:03 AM 19/01/2008, Maya Opperman wrote:

>We have customers in Zimbabwe whose cost prices are now reaching the
>trillions (and growing rapidly).
>
>The government is refusing to devalue the currency again.
>
>I am using decimal(18,5) to store the monetary values for our accounting
>system. (In hind-sight decimal(18,2) would have given us a little more
>lee-way)

Definitely! :-) by an order of 3. Numeric(18,2) will store values up to a non-negotiable limit of 92,233,720,368,547,758.07 whereas your highest number with numeric(18,5) is 92,233,720,368,547.75807

>I was wondering, are there any plans in the pipeline to increase the
>maximum size allowed for the decimal data type?

No. There are no plans in the pipeline to support 128-bit integers in Firebird 2.5 or Firebird 3. About the future - who knows?

>Or [...] there is another data type I can use already..?

You can use double precision to stretch the boundaries, provided your dynamic SQL and PSQL deal accurately enough with the issues of rounding and scale. You would probably find this tech info paper quite helpful:

http://www.ibobjects.com/docs/TI_Numerics.rtf

But just realise that multiplying and dividing fixed numerics has serious issues for scale, i.e., storage is only one part of your problem. Do think seriously about reducing the scale of your stored numerics. If you really do have a requirement to store some currency values in thousandths of cents (or even in tenths of cents) your accountant should be able to provide some requirements to help you develop the appropriate alternative algorithms for storing and calculating the actual fields that have these requirements.

./heLen