>age numeric(4,2)
>Overflow Error: Can't set AGE with 37.9!
Yeah. 37.9 is a numeric(5,2) value so that it failed. For age, maybe you should use numeric(6,2), since there's some men with an over one hundred ages .

Re:Re:Numeric Overflow Error.

Edwin S. Ramirez

2007-10-29 07:22:27.0

Actually, 37.9 is numeric(3,1). Three digits, two for the non-decimal (37) and one decimal (9) place. This is the interpretation supported by Oracle, Postgres, SQL server, etc.

The first NUMERIC(p, s) parameter (p) specifies the precision (the total number of digits) and the second (s) parameter specifies the scale (the number of digits in the fractional part). If you provide only one parameter, an ANSI-compliant database interprets it as the precision of a fixed-point number and the default scale is 0. If you specify no parameters, and the database is ANSI-compliant, then by default the precision is 16 and the scale is 0.

Are you using the behavior of java.math.BigDecimal to define the database types?

Thanks,
-Edwin S. Ramirez-

Re:Re:Re:Numeric Overflow Error.

HXTT Support

2007-10-29 07:46:30.0

>This is the interpretation supported by Oracle, Postgres, SQL server, etc.
>Are you using the behavior of java.math.BigDecimal to define the database types?
Yeah. 37.9 will be translated into 37.90, so that it will be refused. Some databases use string to store NUMERIC value, and other databases using double, long, or other way to store NUMERIC value.

>The first NUMERIC(p, s) parameter (p) specifies the precision (the total number
> of digits) and the second (s) parameter specifies the scale (the number of digits
>in the fractional part).
So the question is what's the scale meaning? A fixed number of digits in the fractional part(HXTT drivers use), or a max number of digits in the fractional part(you expect).

Re:Re:Re:Re:Numeric Overflow Error.

Edwin S. Ramirez

2007-10-29 07:59:14.0

But wouldn't 37.9 then be a NUMERIC(4,2) to accommodate 37.90?

The problem is that all the database definitions that already exists in Oracle, Postgres, etc. will not work in HXTT. The ANSI standard expects a numeric data type to only store/produce the specified values. So if I defined NUMERIC(3,1) then the largest value that I can store is 99.9

Is the translation necessary? Keep in mind that the purpose of NUMERIC is to retain the precision of the input.

Thanks
-Edwin S. Ramirez-

Re:Re:Re:Re:Re:Numeric Overflow Error.

HXTT Support

2007-10-29 16:49:03.0

>But wouldn't 37.9 then be a NUMERIC(4,2) to accommodate 37.90?
>So if I defined NUMERIC(3,1) then the largest value that I can store is 99.9
Because radix point need to occupy one byte, which be calculated into precision.

Re:Re:Re:Re:Re:Re:Numeric Overflow Error.

Edwin S. Ramirez

2007-10-29 17:05:53.0

Wait, which one is it? The point or the extra zero at the end. How are these numbers stored internally?

You are changing the specification. Do what you need to do without misinterpreting the database type spec. If you need an extra byte for the point, add it automatically, and behind the scene.

Thanks,
-Edwin S. Ramirez-

Re:Re:Re:Re:Re:Re:Re:Numeric Overflow Error.

HXTT Support

2007-10-29 18:34:33.0

Not me change, just for compatibility:) In VFP and old Mysql 3.3.x, radix point will be calculated into precision. We will change that action to work like most databases in the next minor upgrade.

Re:Re:Re:Re:Re:Re:Re:Re:Numeric Overflow Error.

HXTT Support

2007-10-30 04:22:02.0

Thanks. Changed according to your suggesion. The next minor version should be available when we have complemented the Excel formating support.

Re:Numeric Overflow Error.

Edwin S. Ramirez

2007-11-16 18:01:29.0

Any word on the status of this request?

I downloaded the latest version (4.0) today and I am getting the following error: