Author: paul
Date: 2006-01-05 21:45:02 +0100 (Thu, 05 Jan 2006)
New Revision: 692
Log:
r5877@frost: paul | 2006-01-05 14:14:37 -0600
General revisions.
Modified:
trunk/
trunk/refman-4.1/introduction.xml
trunk/refman-5.0/introduction.xml
trunk/refman-5.1/introduction.xml
Property changes on: trunk
___________________________________________________________________
Name: svk:merge
- b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:5876
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:1933
+ b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:5877
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:1933
Modified: trunk/refman-4.1/introduction.xml
===================================================================
--- trunk/refman-4.1/introduction.xml 2006-01-05 20:44:31 UTC (rev 691)
+++ trunk/refman-4.1/introduction.xml 2006-01-05 20:45:02 UTC (rev 692)
@@ -2816,7 +2816,7 @@
</para>
<para>
- The following sections describe what happens for the different
+ The following sections describe how MySQL Server handles different
types of constraints.
</para>
@@ -2852,24 +2852,28 @@
</para>
<para>
- If you wish to ignore such key violations, MySQL supports an
+ If you want to ignore such key violations, MySQL supports an
<literal>IGNORE</literal> keyword for
<literal>INSERT</literal> and <literal>UPDATE</literal>. In
this case, MySQL ignores any key violations and continues
- processing with the next row. See <xref linkend="insert"/>.
- See <xref linkend="update"/>.
+ processing with the next row. See <xref linkend="insert"/>, and
+ <xref linkend="update"/>.
</para>
<para>
You can get information about the number of rows actually
inserted or updated with the <literal>mysql_info()</literal> C
- API function. See <xref linkend="mysql-info"/>. In MySQL 4.1
+ API function.
+In MySQL 4.1
and up, you also can use the <literal>SHOW WARNINGS</literal>
- statement. See <xref linkend="show-warnings"/>.
+ statement.
+See <xref linkend="mysql-info"/>, and
+<xref linkend="show-warnings"/>.
</para>
<para>
- Through MySQL 4.1, only <literal>InnoDB</literal> tables
+Currently,
+ only <literal>InnoDB</literal> tables
support foreign keys. See
<xref linkend="innodb-foreign-key-constraints"/>. (Foreign key
support in <literal>MyISAM</literal> tables is scheduled for
@@ -2910,20 +2914,21 @@
<para>
Through version 4.1, MySQL is forgiving of illegal or improper
data values and coerces them to legal values for data entry.
- If you insert an <quote>incorrect</quote> value into a column,
+ When you insert an <quote>incorrect</quote> value into a column,
such as a <literal>NULL</literal> into a <literal>NOT
NULL</literal> column or a too-large numeric value into a
numeric column, MySQL sets the column to the <quote>best
- possible value</quote> instead of producing an error:
+ possible value</quote> instead of producing an error.
+The following rules describe in more detail how this works:
</para>
<itemizedlist>
<listitem>
<para>
- If you try to store an out of range value in a numeric
+ If you try to store an out of range value into a numeric
column, MySQL Server instead stores zero, the smallest
- possible value, or the largest possible value in the
+ possible value, or the largest possible value, whichever is closest to the invalid value.
column.
</para>
</listitem>
@@ -2944,6 +2949,12 @@
<listitem>
<para>
+Invalid values for <literal>ENUM</literal> and <literal>SET</literal> columns ae handled as described in <xref linkend="constraint-enum"/>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
MySQL allows you to store certain incorrect date values
into <literal>DATE</literal> and
<literal>DATETIME</literal> columns (such as
@@ -2953,7 +2964,7 @@
can store a date value and retrieve exactly the same
value, MySQL stores it as given. If the date is totally
wrong (outside the server's ability to store it), the
- special date value <literal>'0000-00-00'</literal> is
+ special <quote>zero</quote> date value <literal>'0000-00-00'</literal> is
stored in the column instead.
</para>
</listitem>
@@ -2989,7 +3000,7 @@
</itemizedlist>
<para>
- The reason for the preceding rules is that we can't check
+ The reason for using the preceding rules is that we can't check
these conditions until the statement has begun executing. We
can't just roll back if we encounter a problem after updating
a few rows, because the storage engine may not support
Modified: trunk/refman-5.0/introduction.xml
===================================================================
--- trunk/refman-5.0/introduction.xml 2006-01-05 20:44:31 UTC (rev 691)
+++ trunk/refman-5.0/introduction.xml 2006-01-05 20:45:02 UTC (rev 692)
@@ -2459,18 +2459,18 @@
<para>
Beginning with MySQL 5.0.2, several SQL mode options are
- available to provide greater control over how accepting to be of
- bad data values and whether to continue executing a statement or
- abort it when errors occur. Using these options, you can
+ available to provide greater control over handling of
+ bad data values and whether to continue statement execution or
+ abort when errors occur. Using these options, you can
configure MySQL Server to act in a more traditional fashion that
is like other DBMSs that reject improper input. The SQL mode can
- be set at runtime, which enables individual clients to select
- the behavior most appropriate for their requirements. See
+ be set globally at server startup to affect all clients. Individual clients can set the SQL mode at runtime, which enables each client to select
+ the behavior most appropriate for its requirements. See
<xref linkend="server-sql-mode"/>.
</para>
<para>
- The following sections describe what happens for the different
+ The following sections describe how MySQL Server handles different
types of constraints.
</para>
@@ -2506,24 +2506,27 @@
</para>
<para>
- If you wish to ignore such key violations, MySQL supports an
+ If you want to ignore such key violations, MySQL supports an
<literal>IGNORE</literal> keyword for
<literal>INSERT</literal> and <literal>UPDATE</literal>. In
this case, MySQL ignores any key violations and continues
- processing with the next row. See <xref linkend="insert"/>.
- See <xref linkend="update"/>.
+ processing with the next row. See <xref linkend="insert"/>, and
+ <xref linkend="update"/>.
</para>
<para>
You can get information about the number of rows actually
inserted or updated with the <literal>mysql_info()</literal> C
- API function. See <xref linkend="mysql-info"/>. In MySQL 4.1
+ API function.
+In MySQL 4.1
and up, you also can use the <literal>SHOW WARNINGS</literal>
- statement. See <xref linkend="show-warnings"/>.
+ statement.
+See <xref linkend="mysql-info"/>, and
+<xref linkend="show-warnings"/>.
</para>
<para>
- Through MySQL 5.0, only <literal>InnoDB</literal> tables
+ Currently, only <literal>InnoDB</literal> tables
support foreign keys. See
<xref linkend="innodb-foreign-key-constraints"/>. Foreign key
support in <literal>MyISAM</literal> tables is scheduled for
@@ -2565,29 +2568,36 @@
Before MySQL 5.0.2, MySQL is forgiving of illegal or improper
data values and coerces them to legal values for data entry.
In MySQL 5.0.2 and up, that remains the default behavior, but
- you can select more traditional treatment of bad values such
+ you can change the server SQL mode to select more traditional treatment of bad values such
that the server rejects them and aborts the statement in which
- they occur. This section describes the default (forgiving)
+ they occur.
+ <xref linkend="server-sql-mode"/>.
+</para>
+
+<para>
+ This section describes the default (forgiving)
behavior of MySQL, as well as the newer strict SQL mode and
how it differs.
</para>
<para>
- The following holds true when you are not using strict mode.
- If you insert an <quote>incorrect</quote> value into a column,
+ If you are not using strict mode, then whenever
+ you insert an <quote>incorrect</quote> value into a column,
such as a <literal>NULL</literal> into a <literal>NOT
NULL</literal> column or a too-large numeric value into a
numeric column, MySQL sets the column to the <quote>best
possible value</quote> instead of producing an error:
+The following rules describe in more detail how this works:
</para>
<itemizedlist>
<listitem>
<para>
- If you try to store an out of range value in a numeric
+ If you try to store an out of range value into a numeric
column, MySQL Server instead stores zero, the smallest
- possible value, or the largest possible value in the
+ possible value, or the largest possible value, whichever is
+closest to the invalid value.
column.
</para>
</listitem>
@@ -2608,6 +2618,12 @@
<listitem>
<para>
+Invalid values for <literal>ENUM</literal> and <literal>SET</literal> columns ae handled as described in <xref linkend="constraint-enum"/>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
MySQL allows you to store certain incorrect date values
into <literal>DATE</literal> and
<literal>DATETIME</literal> columns (such as
@@ -2617,7 +2633,7 @@
can store a date value and retrieve exactly the same
value, MySQL stores it as given. If the date is totally
wrong (outside the server's ability to store it), the
- special date value <literal>'0000-00-00'</literal> is
+ special <quote>zero</quote> date value <literal>'0000-00-00'</literal> is
stored in the column instead.
</para>
</listitem>
@@ -2653,7 +2669,7 @@
</itemizedlist>
<para>
- The reason for the preceding rules is that we can't check
+ The reason for using the preceding rules in non-strict mode is that we can't check
these conditions until the statement has begun executing. We
can't just roll back if we encounter a problem after updating
a few rows, because the storage engine may not support
@@ -2668,12 +2684,17 @@
In MySQL 5.0.2 and up, you can select stricter treatment of
input values by using the
<literal>STRICT_TRANS_TABLES</literal> or
- <literal>STRICT_ALL_TABLES</literal> SQL modes. See
- <xref linkend="server-sql-mode"/>.
+ <literal>STRICT_ALL_TABLES</literal> SQL modes:
</para>
+<programlisting>
+SET sql_mode = 'STRICT_TRANS_TABLES';
+SET sql_mode = 'STRICT_ALL_TABLES';
+</programlisting>
+
<para>
- <literal>STRICT_TRANS_TABLES</literal> works like this:
+ <literal>STRICT_TRANS_TABLES</literal> enables strict mode for transactional storage engines, and also to some extent for non-transactional engines.
+It works like this:
</para>
<itemizedlist>
@@ -2681,30 +2702,31 @@
<listitem>
<para>
For transactional storage engines, bad data values
- occurring anywhere in the statement cause the statement to
+ occurring anywhere in a statement cause the statement to
abort and roll back.
</para>
</listitem>
<listitem>
<para>
- For non-transactional storage engines, the statement
+ For non-transactional storage engines, a statement
aborts if the error occurs in the first row to be inserted
- or updated. (In this case, the statement can be regarded
- to leave the table unchanged, just as for a transactional
+ or updated. (When the error occurs in the first row, the statement can be aborted to leave the table
+unchanged, just as for a transactional
table.) Errors in rows after the first do not abort the
- statement. Instead, bad data values are adjusted and
+ statement, because the table has already been changed by the first row. Instead, bad data values are adjusted and
result in warnings rather than errors. In other words,
with <literal>STRICT_TRANS_TABLES</literal>, a wrong value
- causes MySQL to roll back, if it can, all updates done so
- far.
+ causes MySQL to roll back all updates done so
+ far, if that can be done without changing the table.
+But once the table has been changed, further errors result in adjustments and warnings.
</para>
</listitem>
</itemizedlist>
<para>
- For stricter checking, enable
+ For even stricter checking, enable
<literal>STRICT_ALL_TABLES</literal>. This is the same as
<literal>STRICT_TRANS_TABLES</literal> except that for
non-transactional storage engines, errors abort the statement
Modified: trunk/refman-5.1/introduction.xml
===================================================================
--- trunk/refman-5.1/introduction.xml 2006-01-05 20:44:31 UTC (rev 691)
+++ trunk/refman-5.1/introduction.xml 2006-01-05 20:45:02 UTC (rev 692)
@@ -2218,18 +2218,18 @@
<para>
Several SQL mode options are available to provide greater
- control over how accepting to be of bad data values and whether
- to continue executing a statement or abort it when errors occur.
+ control over handling of bad data values and whether
+ to continue statement execution or abort when errors occur.
Using these options, you can configure MySQL Server to act in a
more traditional fashion that is like other DBMSs that reject
- improper input. The SQL mode can be set at runtime, which
- enables individual clients to select the behavior most
- appropriate for their requirements. See
+ improper input. The SQL mode can be set
+ globally at server startup to affect all clients. Individual clients can set the SQL mode at runtime, which enables each client to select
+ the behavior most appropriate for its requirements. See
<xref linkend="server-sql-mode"/>.
</para>
<para>
- The following sections describe what happens for the different
+ The following sections describe how MySQL Server handles different
types of constraints.
</para>
@@ -2265,24 +2265,27 @@
</para>
<para>
- If you wish to ignore such key violations, MySQL supports an
+ If you want to ignore such key violations, MySQL supports an
<literal>IGNORE</literal> keyword for
<literal>INSERT</literal> and <literal>UPDATE</literal>. In
this case, MySQL ignores any key violations and continues
- processing with the next row. See <xref linkend="insert"/>.
- See <xref linkend="update"/>.
+ processing with the next row. See <xref linkend="insert"/>, and
+ <xref linkend="update"/>.
</para>
<para>
You can get information about the number of rows actually
inserted or updated with the <literal>mysql_info()</literal> C
- API function. See <xref linkend="mysql-info"/>. In MySQL 4.1
+ API function.
+In MySQL 4.1
and up, you also can use the <literal>SHOW WARNINGS</literal>
- statement. See <xref linkend="show-warnings"/>.
+ statement.
+See <xref linkend="mysql-info"/>, and
+<xref linkend="show-warnings"/>.
</para>
<para>
- Through MySQL 5.1, only <literal>InnoDB</literal> tables
+ Currently, only <literal>InnoDB</literal> tables
support foreign keys. See
<xref linkend="innodb-foreign-key-constraints"/>. Foreign key
support in <literal>MyISAM</literal> tables is scheduled for
@@ -2324,29 +2327,36 @@
Before MySQL 5.0.2, MySQL is forgiving of illegal or improper
data values and coerces them to legal values for data entry.
In MySQL 5.0.2 and up, that remains the default behavior, but
- you can select more traditional treatment of bad values such
+ you can change the server SQL mode to select more traditional treatment of bad values such
that the server rejects them and aborts the statement in which
- they occur. This section describes the default (forgiving)
+ they occur.
+ <xref linkend="server-sql-mode"/>.
+</para>
+
+<para>
+ This section describes the default (forgiving)
behavior of MySQL, as well as the newer strict SQL mode and
how it differs.
</para>
<para>
- The following holds true when you are not using strict mode.
- If you insert an <quote>incorrect</quote> value into a column,
+ If you are not using strict mode, then whenever
+ you insert an <quote>incorrect</quote> value into a column,
such as a <literal>NULL</literal> into a <literal>NOT
NULL</literal> column or a too-large numeric value into a
numeric column, MySQL sets the column to the <quote>best
possible value</quote> instead of producing an error:
+The following rules describe in more detail how this works:
</para>
<itemizedlist>
<listitem>
<para>
- If you try to store an out of range value in a numeric
+ If you try to store an out of range value into a numeric
column, MySQL Server instead stores zero, the smallest
- possible value, or the largest possible value in the
+ possible value, or the largest possible value, whichever is
+closest to the invalid value.
column.
</para>
</listitem>
@@ -2367,6 +2377,12 @@
<listitem>
<para>
+Invalid values for <literal>ENUM</literal> and <literal>SET</literal> columns ae handled as described in <xref linkend="constraint-enum"/>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
MySQL allows you to store certain incorrect date values
into <literal>DATE</literal> and
<literal>DATETIME</literal> columns (such as
@@ -2376,7 +2392,7 @@
can store a date value and retrieve exactly the same
value, MySQL stores it as given. If the date is totally
wrong (outside the server's ability to store it), the
- special date value <literal>'0000-00-00'</literal> is
+ special <quote>zero</quote> date value <literal>'0000-00-00'</literal> is
stored in the column instead.
</para>
</listitem>
@@ -2412,7 +2428,7 @@
</itemizedlist>
<para>
- The reason for the preceding rules is that we can't check
+ The reason for using the preceding rules in non-strict mode is that we can't check
these conditions until the statement has begun executing. We
can't just roll back if we encounter a problem after updating
a few rows, because the storage engine may not support
@@ -2427,12 +2443,17 @@
In MySQL 5.0.2 and up, you can select stricter treatment of
input values by using the
<literal>STRICT_TRANS_TABLES</literal> or
- <literal>STRICT_ALL_TABLES</literal> SQL modes. See
- <xref linkend="server-sql-mode"/>.
+ <literal>STRICT_ALL_TABLES</literal> SQL modes:
</para>
+<programlisting>
+SET sql_mode = 'STRICT_TRANS_TABLES';
+SET sql_mode = 'STRICT_ALL_TABLES';
+</programlisting>
+
<para>
- <literal>STRICT_TRANS_TABLES</literal> works like this:
+ <literal>STRICT_TRANS_TABLES</literal> enables strict mode for transactional storage engines, and also to some extent for non-transactional engines.
+It works like this:
</para>
<itemizedlist>
@@ -2440,30 +2461,31 @@
<listitem>
<para>
For transactional storage engines, bad data values
- occurring anywhere in the statement cause the statement to
+ occurring anywhere in a statement cause the statement to
abort and roll back.
</para>
</listitem>
<listitem>
<para>
- For non-transactional storage engines, the statement
+ For non-transactional storage engines, a statement
aborts if the error occurs in the first row to be inserted
- or updated. (In this case, the statement can be regarded
- to leave the table unchanged, just as for a transactional
+ or updated. (When the error occurs in the first row, the statement can be aborted to leave the table
+unchanged, just as for a transactional
table.) Errors in rows after the first do not abort the
- statement. Instead, bad data values are adjusted and
+ statement, because the table has already been changed by the first row. Instead, bad data values are adjusted and
result in warnings rather than errors. In other words,
with <literal>STRICT_TRANS_TABLES</literal>, a wrong value
- causes MySQL to roll back, if it can, all updates done so
- far.
+ causes MySQL to roll back all updates done so
+ far, if that can be done without changing the table.
+But once the table has been changed, further errors result in adjustments and warnings.
</para>
</listitem>
</itemizedlist>
<para>
- For stricter checking, enable
+ For even stricter checking, enable
<literal>STRICT_ALL_TABLES</literal>. This is the same as
<literal>STRICT_TRANS_TABLES</literal> except that for
non-transactional storage engines, errors abort the statement
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r692 - in trunk: . refman-4.1 refman-5.0 refman-5.1 | paul | 5 Jan |
