>
> Corey, if you were using IB5.6 previously, you should have gotten a numeric
> overflow in those cases where IB6-dialect1 produces negative results.
>

Are you sure about that? One of the cited examples
was 3500 * 1 which did not even approach overflow,
simply gave an incorrect result.

Our app runs fine with IB 5.6, but gives strange data
on IB6.01 in line with this problem (we have numeric
field operations in some select statements).

> I think dialect 1 should conform to IB5.6 behavior as closely as possible
> and also, it can't use INT64. Please, let's discuss this issue in
> IB-Architect, as we are going further than a simple patch. Mark has already
> raised the priority of the bug solution.
>
> C.
>

I can't see a problem in promoting to INT64 for the
internal calculations. As long as the correct result
is returned -- i.e. a cast to the assumed result type,
with overflow checking on the conversion.

If we need to emulate the errors in 5.6's calculations
(would there be any differences? e.g. rounding errors?) by
using double precision, that is of a lower priority to me
than actually getting our app to work.

Best regards,
Corey.