|
Numeric Overflow Error. |
Edwin S. Ramirez |
2007-10-29 06:19:18 |
I don't know what I am doing wrong but I consistenly get this error with any driver, when using Numeric types.
jdbc:dbf:////tmp/dbf/
SQL: create table if not exists names (firstname varchar(100), lastname varchar(100), dob date, age numeric(4,2), cmnt varchar(1000))
DBF Setup Done
Connecting to text ////tmp/data.csv
jdbc:csv:////tmp/data.csv?readOnlyMode=true;maxScanRows=0;_CSV_Header=true;
Text Setup Done
=====================================================
SQL: select * from data
=====================================================
SQL: insert into names (firstname, lastname, dob, age, cmnt) values (?, ?, ?, ?, ?)
0 [VARCHAR]-> Edwin
1 [VARCHAR]-> Ramirez
2 [VARCHAR]-> 1970-11-05
3 [VARCHAR]-> 37.9
4 [VARCHAR]-> This is a comment
dbReader: JavaException: java.sql.SQLException: Overflow Error: Can't set AGE with 37.9!
Thanks,
-Edwin S. Ramirez-
|
Re:Numeric Overflow Error. |
HXTT Support |
2007-10-29 07:06:59 |
>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 |
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 |
>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 |
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 |
>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 |
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 |
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 |
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 |
Any word on the status of this request?
I downloaded the latest version (4.0) today and I am getting the following error:
java.lang.NoSuchMethodError: com.hxtt.sql.de.a(ILjava/lang/String;Ljava/util/Properties;)Lcom/hxtt/concurrent/ab;
at com.hxtt.sql.text.EmbeddedDriver.connect(Unknown Source)
at com.hxtt.global.SQLState.getConnection(Unknown Source)
at com.hxtt.sql.HxttDriver.if(Unknown Source)
at com.hxtt.sql.HxttDriver.connect(Unknown Source)
Thanks,
-Edwin S. Ramirez-
|
Re:Re:Re:Re:Re:Re:Re:Re:Numeric Overflow Error. |
HXTT Support |
2007-11-19 06:17:05 |
>I downloaded the latest version (4.0) today and I am getting the following error:
>java.lang.NoSuchMethodError:
Try to redownload the new package.
>radix point will be calculated into precision. We will change that action to
> work like most databases in the next minor upgrade.
Supported.
>when we have complemented the Excel formating support.
We haven't complemented all formating still. Please wait a few days. For instance,
update testprecision set age='_Style_;borderType=all;borderLineStyle=DASH_DOT_DOT;borderColour=LIME;rowHeight=deafult;rowCollapsed=true;' where recno()=3;
We have complement the following format support:
property parameter
(case insensitive)
value (case insensitive)
border borderType NONE, ALL, TOP, BOTTOM, LEFT, RIGHT
borderLineStyle optional NONE, THIN, MEDIUM, DASHED, DOTTED, THICK, DOUBLE, HAIR, MEDIUM_DASHED, DASH_DOT, MEDIUM_DASH_DOT, DASH_DOT_DOT, MEDIUM_DASH_DOT_DOT, SLANTED_DASH_DOT
borderColour optional BLACK, WHITE, DEFAULT_BACKGROUND1, DEFAULT_BACKGROUND, PALETTE_BLACK, RED, BRIGHT_GREEN, BLUE, YELLOW, PINK, TURQUOISE, DARK_RED, GREEN, DARK_BLUE, DARK_YELLOW, VIOLET, TEAL, GREY_25_PERCENT, GREY_50_PERCENT, PERIWINKLE, PLUM2, IVORY, LIGHT_TURQUOISE2, DARK_PURPLE, CORAL, OCEAN_BLUE, ICE_BLUE, DARK_BLUE2, PINK2, YELLOW2, TURQOISE2, VIOLET2, DARK_RED2, TEAL2, BLUE2, SKY_BLUE, LIGHT_TURQUOISE, LIGHT_GREEN, VERY_LIGHT_YELLOW, PALE_BLUE, ROSE, LAVENDER, TAN, LIGHT_BLUE, AQUA, LIME, GOLD, LIGHT_ORANGE, ORANGE, BLUE_GREY, GREY_40_PERCENT, DARK_TEAL, SEA_GREEN, DARK_GREEN, OLIVE_GREEN, BROWN, PLUM, INDIGO, GREY_80_PERCENT, AUTOMATIC
row rowHeight optional default, or a double value in point
rowCollapsed optional true, false
cell cellFontName optional
cellRotationAngle optional HORIZONTAL, VERTICAL, PLUS_90, MINUS_90
|
|
|