Alden Hosting provides professional, efficient, and reliable businessclass Web hosting services to small and mediumsized businesses. 

JAVA, JSP, SERVLETS, TOMCAT, SERVLETS MANAGER, 
Leftover Digits  Number of Bytes 
0  0 
1  1 
2  1 
3  2 
4  2 
5  3 
6  3 
7  4 
8  4 
9  4 
As a result of the change from string to numeric format for
DECIMAL
storage, DECIMAL
columns no longer store a leading +
character
or leading 0
digits. Before MySQL 5.0.3, if you
inserted +0003.1
into a
DECIMAL(5,1)
column, it was stored as
+0003.1
. As of MySQL 5.0.3, it is stored as
3.1
. Applications that rely on the older
behavior must be modified to account for this change.
The change of storage format also means that
DECIMAL
columns no longer support the
nonstandard extension that allowed values larger than the range
implied by the column definition. Formerly, one byte was allocated
for storing the sign character. For positive values that needed no
sign byte, MySQL allowed an extra digit to be stored instead. For
example, a DECIMAL(3,0)
column must support a
range of at least –999
to
999
, but MySQL would allow storing values from
1000
to 9999
as well, by
using the sign byte to store an extra digit. This extension to the
upper range of DECIMAL
columns no longer is
allowed. In MySQL 5.0.3 and up, a
DECIMAL(
column allows at most
M
,D
)M
−D
digits
to the left of the decimal point. This can result in an
incompatibility if an application has a reliance on MySQL allowing
“toolarge” values.
The SQL standard requires that the precision of
NUMERIC(
be exactly M
,D
)M
digits. For
DECIMAL(
,
the standard requires a precision of at least
M
,D
)M
digits but allows more. In MySQL,
DECIMAL(
and
M
,D
)NUMERIC(
are the same, and both have a precision of exactly
M
,D
)M
digits.
Summary of incompatibilities:
The following list summarizes the incompatibilities that result
from changes to DECIMAL
column and value
handling. You can use it as guide when porting older applications
for use with MySQL 5.0.3 and up.
For
DECIMAL(
,
the maximum M
,D
)M
is 65, not 254.
Calculations involving exactvalue decimal numbers are accurate to 65 digits. This is fewer than the maximum number of digits allowed before MySQL 5.0.3 (254 digits), but the exactvalue precision is greater. Calculations formerly were done with doubleprecision floatingpoint, which has a precision of 52 bits (about 15 decimal digits).
The nonstandard MySQL extension to the upper range of
DECIMAL
columns no longer is supported.
Leading ‘+
’ and
‘0
’ characters are not stored.
The behavior used by the server for DECIMAL
columns in a table depends on the version of MySQL used to create
the table. If your server is from MySQL 5.0.3 or higher, but you
have DECIMAL
columns in tables that were
created before 5.0.3, the old behavior still applies to those
columns. To convert the tables to the newer
DECIMAL
format, dump them with
mysqldump and reload them.
With precision math, exactvalue numbers are used as given
whenever possible. For example, numbers in comparisons are used
exactly as given without a change in value. In strict SQL mode,
for INSERT
into a column with an exact data
type (DECIMAL
or integer), a number is inserted
with its exact value if it is within the column range. When
retrieved, the value should be the same as what was inserted.
(Without strict mode, truncation for INSERT
is
allowable.)
Handling of a numeric expression depends on what kind of values the expression contains:
If any approximate values are present, the expression is approximate and is evaluated using floatingpoint arithmetic.
If no approximate values are present, the expression contains
only exact values. If any exact value contains a fractional
part (a value following the decimal point), the expression is
evaluated using DECIMAL
exact arithmetic
and has a precision of 65 digits. (The term
“exact” is subject to the limits of what can be
represented in binary. For example, 1.0/3.0
can be approximated in decimal notation as
.333...
, but not written as an exact
number, so (1.0/3.0)*3.0
does not evaluate
to exactly 1.0
.)
Otherwise, the expression contains only integer values. The
expression is exact and is evaluated using integer arithmetic
and has a precision the same as BIGINT
(64
bits).
If a numeric expression contains any strings, they are converted to doubleprecision floatingpoint values and the expression is approximate.
Inserts into numeric columns are affected by the SQL mode, which
is controlled by the sql_mode
system variable.
(See Section 5.2.6, “SQL Modes”.) The following discussion
mentions strict mode (selected by the
STRICT_ALL_TABLES
or
STRICT_TRANS_TABLES
mode values) and
ERROR_FOR_DIVISION_BY_ZERO
. To turn on all
restrictions, you can simply use TRADITIONAL
mode, which includes both strict mode values and
ERROR_FOR_DIVISION_BY_ZERO
:
mysql> SET sql_mode='TRADITIONAL';
If a number is inserted into an exact type column
(DECIMAL
or integer), it is inserted with its
exact value if it is within the column range.
If the value has too many digits in the fractional part, rounding occurs and a warning is generated. Rounding is done as described in Section 21.4, “Rounding Behavior”.
If the value has too many digits in the integer part, it is too large and is handled as follows:
If strict mode is not enabled, the value is truncated to the nearest legal value and a warning is generated.
If strict mode is enabled, an overflow error occurs.
Underflow is not detected, so underflow handing is undefined.
By default, division by zero produces a result of
NULL
and no warning. With the
ERROR_FOR_DIVISION_BY_ZERO
SQL mode enabled,
MySQL handles division by zero differently:
If strict mode is not enabled, a warning occurs.
If strict mode is enabled, inserts and updates involving division by zero are prohibited, and an error occurs.
In other words, inserts and updates involving expressions that
perform division by zero can be treated as errors, but this
requires ERROR_FOR_DIVISION_BY_ZERO
in addition
to strict mode.
Suppose that we have this statement:
INSERT INTO t SET i = 1/0;
This is what happens for combinations of strict and
ERROR_FOR_DIVISION_BY_ZERO
modes:
sql_mode Value  Result 
'' (Default)  No warning, no error; i is set to
NULL . 
strict  No warning, no error; i is set to
NULL . 
ERROR_FOR_DIVISION_BY_ZERO  Warning, no error; i is set to
NULL . 
strict,ERROR_FOR_DIVISION_BY_ZERO  Error condition; no row is inserted. 
For inserts of strings into numeric columns, conversion from string to number is handled as follows if the string has nonnumeric contents:
A string that does not begin with a number cannot be used as a number and produces an error in strict mode, or a warning otherwise. This includes the empty string.
A string that begins with a number can be converted, but the trailing nonnumeric portion is truncated. If the truncated portion contains anything other than spaces, this produces an error in strict mode, or a warning otherwise.
This section discusses precision math rounding for the
ROUND()
function and for inserts into columns
with exactvalue types (DECIMAL
and integer).
The ROUND()
function rounds differently
depending on whether its argument is exact or approximate:
For exactvalue numbers, ROUND()
uses the
“round half up” rule: A value with a fractional
part of .5 or greater is rounded up to the next integer if
positive or down to the next integer if negative. (In other
words, it is rounded away from zero.) A value with a
fractional part less than .5 is rounded down to the next
integer if positive or up to the next integer if negative.
For approximatevalue numbers, the result depends on the C
library. On many systems, this means that
ROUND()
uses the “round to nearest
even” rule: A value with any fractional part is rounded
to the nearest even integer.
The following example shows how rounding differs for exact and approximate values:
mysql> SELECT ROUND(2.5), ROUND(25E1);
+++
 ROUND(2.5)  ROUND(25E1) 
+++
 3  2 
+++
For inserts into a DECIMAL
or integer column,
the target is an exact data type, so rounding uses “round
half up,” regardless of whether the value to be inserted is
exact or approximate:
mysql>CREATE TABLE t (d DECIMAL(10,0));
Query OK, 0 rows affected (0.00 sec) mysql>INSERT INTO t VALUES(2.5),(2.5E0);
Query OK, 2 rows affected, 2 warnings (0.00 sec) Records: 2 Duplicates: 0 Warnings: 2 mysql>SELECT d FROM t;
++  d  ++  3   3  ++
This section provides some examples that show how precision math improves query results in MySQL 5 compared to older versions.
Example 1. Numbers are used with their exact value as given when possible.
Before MySQL 5.0.3, numbers that are treated as floatingpoint values produce inexact results:
mysql> SELECT .1 + .2 = .3;
++
 .1 + .2 = .3 
++
 0 
++
As of MySQL 5.0.3, numbers are used as given when possible:
mysql> SELECT .1 + .2 = .3;
++
 .1 + .2 = .3 
++
 1 
++
For floatingpoint values, results are inexact:
mysql> SELECT .1E0 + .2E0 = .3E0;
++
 .1E0 + .2E0 = .3E0 
++
 0 
++
Another way to see the difference in exact and approximate value
handling is to add a small number to a sum many times. Consider
the following stored procedure, which adds
.0001
to a variable 1,000 times.
CREATE PROCEDURE p () BEGIN DECLARE i INT DEFAULT 0; DECLARE d DECIMAL(10,4) DEFAULT 0; DECLARE f FLOAT DEFAULT 0; WHILE i < 10000 DO SET d = d + .0001; SET f = f + .0001E0; SET i = i + 1; END WHILE; SELECT d, f; END;
The sum for both d
and f
logically should be 1, but that is true only for the decimal
calculation. The floatingpoint calculation introduces small
errors:
+++  d  f  +++  1.0000  0.99999999999991  +++
Example 2. Multiplication is
performed with the scale required by standard SQL. That is, for
two numbers X1
and
X2
that have scale
S1
and S2
,
the scale of the result is
:
S1
+ S2
Before MySQL 5.0.3, this is what happens:
mysql> SELECT .01 * .01;
++
 .01 * .01 
++
 0.00 
++
The displayed value is incorrect. The value was calculated correctly in this case, but not displayed to the required scale. To see that the calculated value actually was .0001, try this:
mysql> SELECT .01 * .01 + .0000;
++
 .01 * .01 + .0000 
++
 0.0001 
++
As of MySQL 5.0.3, the displayed scale is correct:
mysql> SELECT .01 * .01;
++
 .01 * .01 
++
 0.0001 
++
Example 3. Rounding behavior is welldefined.
Before MySQL 5.0.3, rounding behavior (for example, with the
ROUND()
function) is dependent on the
implementation of the underlying C library. This results in
inconsistencies from platform to platform. For example, you might
get a different value on Windows than on Linux, or a different
value on x86 machines than on PowerPC machines.
As of MySQL 5.0.3, rounding happens like this:
Rounding for exactvalue columns (DECIMAL
and
integer) and exactvalued numbers uses the “round half
up” rule. Values with a fractional part of .5 or greater
are rounded away from zero to the nearest integer, as shown here:
mysql> SELECT ROUND(2.5), ROUND(2.5);
+++
 ROUND(2.5)  ROUND(2.5) 
+++
 3  3 
+++
However, rounding for floatingpoint values uses the C library, which on many systems uses the “round to nearest even” rule. Values with any fractional part on such systems are rounded to the nearest even integer:
mysql> SELECT ROUND(2.5E0), ROUND(2.5E0);
+++
 ROUND(2.5E0)  ROUND(2.5E0) 
+++
 2  2 
+++
Example 4. In strict mode, inserting a value that is too large results in overflow and causes an error, rather than truncation to a legal value.
Before MySQL 5.0.2 (or in 5.0.2 and later, without strict mode), truncation to a legal value occurs:
mysql>CREATE TABLE t (i TINYINT);
Query OK, 0 rows affected (0.01 sec) mysql>INSERT INTO t SET i = 128;
Query OK, 1 row affected, 1 warning (0.00 sec) mysql>SELECT i FROM t;
++  i  ++  127  ++ 1 row in set (0.00 sec)
As of MySQL 5.0.2, overflow occurs if strict mode is in effect:
mysql>SET sql_mode='STRICT_ALL_TABLES';
Query OK, 0 rows affected (0.00 sec) mysql>CREATE TABLE t (i TINYINT);
Query OK, 0 rows affected (0.00 sec) mysql>INSERT INTO t SET i = 128;
ERROR 1264 (22003): Out of range value adjusted for column 'i' at row 1 mysql>SELECT i FROM t;
Empty set (0.00 sec)
Example 5: In strict mode and
with ERROR_FOR_DIVISION_BY_ZERO
set, division
by zero causes an error, and not a result of
NULL
.
Before MySQL 5.0.2 (or when not using strict mode in 5.0.2 or a
later version), division by zero has a result of
NULL
:
mysql>CREATE TABLE t (i TINYINT);
Query OK, 0 rows affected (0.01 sec) mysql>INSERT INTO t SET i = 1 / 0;
Query OK, 1 row affected (0.00 sec) mysql>SELECT i FROM t;
++  i  ++  NULL  ++ 1 row in set (0.00 sec)
As of MySQL 5.0.2, division by zero is an error if the proper SQL modes are in effect:
mysql>SET sql_mode='STRICT_ALL_TABLES,ERROR_FOR_DIVISION_BY_ZERO';
Query OK, 0 rows affected (0.00 sec) mysql>CREATE TABLE t (i TINYINT);
Query OK, 0 rows affected (0.00 sec) mysql>INSERT INTO t SET i = 1 / 0;
ERROR 1365 (22012): Division by 0 mysql>SELECT i FROM t;
Empty set (0.01 sec)
Example 6. Prior to MySQL 5.0.3 (before precision math was introduced), exactvalue and approximatevalue literals both are converted to doubleprecision floatingpoint values:
mysql>SELECT VERSION();
++  VERSION()  ++  4.1.18log  ++ 1 row in set (0.01 sec) mysql>CREATE TABLE t SELECT 2.5 AS a, 25E1 AS b;
Query OK, 1 row affected (0.07 sec) Records: 1 Duplicates: 0 Warnings: 0 mysql>DESCRIBE t;
+++++++  Field  Type  Null  Key  Default  Extra  +++++++  a  double(3,1)    0.0    b  double    0   +++++++ 2 rows in set (0.04 sec)
As of MySQL 5.0.3, the approximatevalue literal still is
converted to floatingpoint, but the exactvalue literal is
handled as DECIMAL
:
mysql>SELECT VERSION();
++  VERSION()  ++  5.0.19log  ++ 1 row in set (0.17 sec) mysql>CREATE TABLE t SELECT 2.5 AS a, 25E1 AS b;
Query OK, 1 row affected (0.19 sec) Records: 1 Duplicates: 0 Warnings: 0 mysql>DESCRIBE t;
+++++++  Field  Type  Null  Key  Default  Extra  +++++++  a  decimal(2,1) unsigned  NO   0.0    b  double  NO   0   +++++++ 2 rows in set (0.02 sec)
Example 7. If the argument to an aggregate function is an exact numeric type, the result is also an exact numeric type, with a scale at least that of the argument.
Consider these statements:
mysql>CREATE TABLE t (i INT, d DECIMAL, f FLOAT);
mysql>INSERT INTO t VALUES(1,1,1);
mysql>CREATE TABLE y SELECT AVG(i), AVG(d), AVG(f) FROM t;
Result before MySQL 5.0.3 (prior to the introduction of precision math in MySQL):
mysql> DESCRIBE y;
+++++++
 Field  Type  Null  Key  Default  Extra 
+++++++
 AVG(i)  double(17,4)  YES   NULL  
 AVG(d)  double(17,4)  YES   NULL  
 AVG(f)  double  YES   NULL  
+++++++
The result is a double no matter the argument type.
Result as of MySQL 5.0.3:
mysql> DESCRIBE y;
+++++++
 Field  Type  Null  Key  Default  Extra 
+++++++
 AVG(i)  decimal(14,4)  YES   NULL  
 AVG(d)  decimal(14,4)  YES   NULL  
 AVG(f)  double  YES   NULL  
+++++++
The result is a double only for the floatingpoint argument. For
exact type arguments, the result is also an exact type. (From
MySQL 5.0.3 to 5.0.6, the first two columns are
DECIMAL(64,0)
.)
Alden Hosting offers private JVM (Java Virtual Machine), Java Server Pages (JSP), Servlets, and Servlets Manager with our Web Hosting Plans WEB 4 PLAN and WEB 5 PLAN , WEB 6 PLAN .
At Alden Hosting we eat and breathe Java! We are the industry leader in providing affordable, quality and efficient Java web hosting in the shared hosting marketplace. All our sites run on our Java hosing platform configured for optimum performance using Java 1.6, Tomcat 6, MySQL 5, Apache 2.2 and web application frameworks such as Struts, Hibernate, Cocoon, Ant, etc.
We offer only one type of Java hosting  Private Tomcat. Hosting accounts on the Private Tomcat environment get their very own Tomcat server. You can start and restart your entire Tomcat server yourself.

http://aldenservletHosting.com
JSP at aldenservletHosting.com
Servlets at aldenservletHosting.com
Servlet at aldenservletHosting.com
Tomcat at aldenservletHosting.com
MySQL at aldenservletHosting.com
Java at aldenservletHosting.com
sFTP at aldenservletHosting.com
http://aldentomcatHosting.com
JSP at aldentomcatHosting.com
Servlets at aldentomcatHosting.com
Servlet at aldentomcatHosting.com
Tomcat at aldentomcatHosting.com
MySQL at aldentomcatHosting.com
Java at aldentomcatHosting.com
sFTP at aldentomcatHosting.com
http://aldensftpHosting.com
JSP at aldensftpHosting.com
Servlets at aldensftpHosting.com
Servlet at aldensftpHosting.com
Tomcat at aldensftpHosting.com
MySQL at aldensftpHosting.com
Java at aldensftpHosting.com
sFTP at aldensftpHosting.com
http://aldenjspHosting.com
JSP at aldenjspHosting.com
Servlets at aldenjspHosting.com
Servlet at aldenjspHosting.com
Tomcat at aldenjspHosting.com
MySQL at aldenjspHosting.com
Java at aldenjspHosting.com
sFTP at aldenjspHosting.com
http://aldenjavaHosting.com
JSp at aldenjavaHosting.com
Servlets at aldenjavaHosting.com
Servlet at aldenjavaHosting.com
Tomcat at aldenjavaHosting.com
MySQL at aldenjavaHosting.com
Java at aldenjavaHosting.com
sFTP at aldenjavaHosting.com
JSP
Servlets
Tomcat
mysql
Java
JSP
Servlets
Tomcat
mysql
Java
JSP
Servlets
Tomcat
mysql
Java
JSP
Servlets
Tomcat
mysql
Java
JSP at JSP.aldenWEBhosting.com
Servlets at servlets.aldenWEBhosting.com
Tomcat at Tomcat.aldenWEBhosting.com
mysql at mysql.aldenWEBhosting.com
Java at Java.aldenWEBhosting.com
Web Hosts Portal
Web Links
Web Links JSP
Web Links servlet
Tomcat Docs
Web Links
Web Links JSP
Web Links servlet
Web Hosting
Tomcat Docs
JSP Solutions Web Links
JSP Solutions Web Hosting
Servlets Solutions Web Links
Servlets Solutions Web Hosting
Web Links
Web Links
.
.
.
.
.
.
.
.
.
.
jsp hosting
servlets hosting
web hosting
web sites designed
cheap web hosting
web site hosting
myspace web hosting