Oracle 5.0 Reference Manual page 863

column to a string results in a value of
occurs for conversion from
• Values outside the range from
column in a
value of 2011.
To avoid these problems, use
strategies appear later in this section.
Migrating from
YEAR(2)
Should you decide to convert
table has this definition:
t1
CREATE TABLE t1 (ycol YEAR(2) NOT NULL DEFAULT '70');
Modify the column using
as
NOT NULL
ALTER TABLE t1 MODIFY ycol YEAR(4) NOT NULL DEFAULT '1970';
The
ALTER TABLE
a replication master, the
table change on each one.
One migration method should be avoided: Do not dump your data with
dump file after upgrading. This has the potential to change
A migration from
possibility of changed behavior under conditions such as these:
• Code that expects selecting a
• Code that does not account for different handling for inserts of numeric 0: Inserting
or
YEAR(4)
11.1.5.5. Automatic Initialization and Updating for
The
TIMESTAMP
is, the current timestamp). You can choose whether to use these properties and which column should
have them:
• One
TIMESTAMP
the column, as the auto-update value, or both. It is not possible to have the current timestamp be the
default value for one column and the auto-update value for another column.
• If the column is auto-initialized, it is set to the current timestamp for inserted rows that specify no
value for the column.
• If the column is auto-updated, it is automatically updated to the current timestamp when the value
of any other column in the row is changed from its current value. The column remains unchanged
Date and Time Types
YEAR(2)
1970
table. For example, inserting
CSV
YEAR(4)
to
YEAR(4)
YEAR(2)
ALTER TABLE
or DEFAULT:
statement converts the table without changing
ALTER TABLE
to
YEAR(2) YEAR(4)
YEAR
results in an internal value of
Note
In older versions of MySQL (prior to 4.1), the properties of the
data type differed significantly in several ways from what is described in this
section (see the MySQL 3.23, 4.0, 4.1 Reference Manual for details); these
include syntax extensions which are deprecated in MySQL 5.1, and no longer
supported in MySQL 5.5. This has implications for performing a dump and
restore or replicating between MySQL Server versions. If you are using columns
that are defined using the old
"Upgrading from MySQL 4.1 to
data type offers automatic initialization and updating to the current date and time (that
column in a table can have the current timestamp as the default value for initializing
or '1970', respectively. That is, loss of information
'70'
to string.
to are stored incorrectly when inserted into a
2069
results in a display value of
2111
rather than YEAR(2). Suggestions regarding migration
columns to YEAR(4), use
as follows. Remember to include any column attributes such
statement replicates to slaves and makes the corresponding
YEAR(2)
should also involve examining application code for the
column to produce exactly two digits.
or 0000, respectively.
2000
TIMESTAMP
TIMESTAMP(N)
5.0", prior to upgrading to MySQL 5.1 or later.
843
but an internal
11
TABLE. Suppose that a
ALTER
values. If the server is
YEAR(2)
and reload the
mysqldump
values, as described previously.
into
0
TIMESTAMP
syntax, see Section 2.19.1.2,
YEAR(2)
YEAR(2)