List:Commits« Previous MessageNext Message »
From:paul Date:January 5 2006 8:45pm
Subject:svn commit - mysqldoc@docsrva: r692 - in trunk: . refman-4.1 refman-5.0 refman-5.1
View as plain text  
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.1paul5 Jan