Re: The target for a numeric operation is too small to hold theresul t (C G D F)

["Buck Calabro" <buck.calabro@xxxxxxxxxxxx>]

> I have a similar situation where I have two
> different database fields. The result field is
> 10, 4 and the other is 11,4. Obviously too small,
> but what if you don't want to go around changing
> all of the database fields?

Then you lose some numbers.  For instance, say you have an invoice
header file that stores the total invoice amount in a 7,2 field.  This
naturally means you can't have an invoice greater than 99,999.99.  Say
your invoice detail file has a quantity of 5,0 and a price of 5,2.
It's possible to order 200 items (like floor cleaning machines
destined for a hotel chain) at 750.00 per.  Your total invoice less
taxes _should_ be 150,000.00, but it will only be 50,000.00 if you use
MULT.  The MULT will quietly truncate the high-order digit(s), quietly
losing your company 100,000.00.

Then, of course, the wrong amount flows from order entry into A/R, G/L
and probably the salesperson's commissions, which no one will notice
until there is virtually no way to extricate that erroneous
transaction from all the affected systems.

The solutions are to
1) Change your database so you can store the results properly,
2) Change your order entry system so it doesn't allow large invoices,
3) Change your order entry clerks so they don't enter large orders,

I hope this strictly fictional example (ahem) helps illuminate the
issue.
  --buck