Main   Products   Offshore Outsourcing   Customers   Partners   ContactUs  
JDBC Databases
  HXTT Access v5.2
  HXTT Cobol v2.1
  HXTT DBF v5.2
  HXTT Excel v4.2
  HXTT Paradox v5.2
  HXTT Text(CSV) v5.2
 
  Buy Now
  Support
  Download
  Document
  FAQ
  HXTT XML v1.2
Offshore Outsourcing
Oracle Data Import/Export
DB2 Data Import/Export
Sybase Data Import/Export
Free Resources
  Firewall Tunneling
  Search Indexing Robot
  Conditional Compilation
  Password Recovery for MS Access
  Password Recovery for Corel Paradox
  Checksum Tool for MD5
  Character Set Converter
  Pyramid - Poker of ZYH
   
   
   
Hongxin Technology & Trade Ltd. of Xiangtan City (abbr, HXTT)

HXTT Text(CSV)
Numeric Overflow Error.
Edwin S. Ramirez
2007-10-29 06:19:18.0
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.0
>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:

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.0
>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

Search Key   Search by Last 50 Questions




Google
 

Address: 9 Station Rd., Xiangtan City, Hunan Province, P.R. China
Postcode: 411100
Phone: (86)731-58225727
Fax: (86)731-58225727
Email: webmaster@hxtt.com
Copyright © 1999-2011 Hongxin Technology & Trade Ltd. | All Rights Reserved. | Privacy | Legal | Sitemap