List:Commits« Previous MessageNext Message »
From:paul Date:January 5 2006 8:47pm
Subject:svn commit - mysqldoc@docsrva: r695 - in trunk: . refman-4.1 refman-5.0 refman-5.1 refman-common
View as plain text  
Author: paul
Date: 2006-01-05 21:47:18 +0100 (Thu, 05 Jan 2006)
New Revision: 695

Log:
 r5880@frost:  paul | 2006-01-05 14:42:10 -0600
 Reformat.


Modified:
   trunk/
   trunk/refman-4.1/connector-j.xml
   trunk/refman-4.1/connector-odbc.xml
   trunk/refman-4.1/data-types.xml
   trunk/refman-4.1/database-administration.xml
   trunk/refman-4.1/extending-mysql.xml
   trunk/refman-4.1/installing.xml
   trunk/refman-4.1/introduction.xml
   trunk/refman-4.1/ndbcluster.xml
   trunk/refman-4.1/optimization.xml
   trunk/refman-4.1/porting.xml
   trunk/refman-4.1/sql-syntax.xml
   trunk/refman-5.0/client-side-scripts.xml
   trunk/refman-5.0/connector-j.xml
   trunk/refman-5.0/connector-odbc.xml
   trunk/refman-5.0/data-types.xml
   trunk/refman-5.0/database-administration.xml
   trunk/refman-5.0/extending-mysql.xml
   trunk/refman-5.0/installing.xml
   trunk/refman-5.0/introduction.xml
   trunk/refman-5.0/ndbcluster.xml
   trunk/refman-5.0/optimization.xml
   trunk/refman-5.0/porting.xml
   trunk/refman-5.0/restrictions.xml
   trunk/refman-5.0/spatial-extensions.xml
   trunk/refman-5.0/sql-syntax.xml
   trunk/refman-5.0/storage-engines.xml
   trunk/refman-5.1/client-side-scripts.xml
   trunk/refman-5.1/connector-j.xml
   trunk/refman-5.1/connector-odbc.xml
   trunk/refman-5.1/database-administration.xml
   trunk/refman-5.1/extending-mysql.xml
   trunk/refman-5.1/introduction.xml
   trunk/refman-5.1/ndbcluster.xml
   trunk/refman-5.1/optimization.xml
   trunk/refman-5.1/porting.xml
   trunk/refman-5.1/replication.xml
   trunk/refman-5.1/restrictions.xml
   trunk/refman-5.1/spatial-extensions.xml
   trunk/refman-5.1/sql-syntax.xml
   trunk/refman-5.1/storage-engines.xml
   trunk/refman-common/news-4.0.xml
   trunk/refman-common/news-4.1.xml
   trunk/refman-common/news-5.0.xml
   trunk/refman-common/news-5.1.xml


Property changes on: trunk
___________________________________________________________________
Name: svk:merge
   - b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:5879
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:1933
   + b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:5880
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:1933

Modified: trunk/refman-4.1/connector-j.xml
===================================================================
--- trunk/refman-4.1/connector-j.xml	2006-01-05 20:46:05 UTC (rev 694)
+++ trunk/refman-4.1/connector-j.xml	2006-01-05 20:47:18 UTC (rev 695)
@@ -1061,11 +1061,11 @@
         </para>
 
         <para>
-          If you are developing servlets or JSPs, and your
-          application server is J2EE-compliant, you can put the driver's
-          .jar file in the WEB-INF/lib subdirectory of your webapp, as
-          this is a standard location for third party class libraries in
-          J2EE web applications.
+          If you are developing servlets or JSPs, and your application
+          server is J2EE-compliant, you can put the driver's .jar file
+          in the WEB-INF/lib subdirectory of your webapp, as this is a
+          standard location for third party class libraries in J2EE web
+          applications.
         </para>
 
         <para>

Modified: trunk/refman-4.1/connector-odbc.xml
===================================================================
--- trunk/refman-4.1/connector-odbc.xml	2006-01-05 20:46:05 UTC (rev 694)
+++ trunk/refman-4.1/connector-odbc.xml	2006-01-05 20:47:18 UTC (rev 695)
@@ -4992,8 +4992,7 @@
       <para>
         Here is an excellent article from Mike Hillyer
         (<email>m.hillyer@stripped</email>); explaining how to
-        insert or fetch data from blob columns through MyODBC from
-        ADO:
+        insert or fetch data from blob columns through MyODBC from ADO:
         <ulink url="http://www.dynamergy.com/mike/articles/blobaccessvb.html">MySQL
         BLOB columns and Visual Basic 6</ulink>.
       </para>

Modified: trunk/refman-4.1/data-types.xml
===================================================================
--- trunk/refman-4.1/data-types.xml	2006-01-05 20:46:05 UTC (rev 694)
+++ trunk/refman-4.1/data-types.xml	2006-01-05 20:47:18 UTC (rev 695)
@@ -4509,8 +4509,8 @@
         when you assign values to an <literal>ENUM</literal> column. As
         of 4.1.1, <literal>ENUM</literal> columns can be assigned a
         character set and collation. For binary or case-sensitive
-        collations, lettercase does matter when you assign values to
-        the column.
+        collations, lettercase does matter when you assign values to the
+        column.
       </para>
 
       <para>
@@ -4626,8 +4626,8 @@
         when you assign values to an <literal>SET</literal> column. As
         of 4.1.1, <literal>SET</literal> columns can be assigned a
         character set and collation. For binary or case-sensitive
-        collations, lettercase does matter when you assign values to
-        the column.
+        collations, lettercase does matter when you assign values to the
+        column.
       </para>
 
       <para>

Modified: trunk/refman-4.1/database-administration.xml
===================================================================
--- trunk/refman-4.1/database-administration.xml	2006-01-05 20:46:05 UTC (rev 694)
+++ trunk/refman-4.1/database-administration.xml	2006-01-05 20:47:18 UTC (rev 695)
@@ -16694,10 +16694,10 @@
 </programlisting>
 
         <para>
-          After executing this command, the data directory contains
-          a new binary log file,
-          <filename>gbichot2-bin.000007</filename>. The resulting
-          <filename>.sql</filename> file contains these lines:
+          After executing this command, the data directory contains a
+          new binary log file, <filename>gbichot2-bin.000007</filename>.
+          The resulting <filename>.sql</filename> file contains these
+          lines:
         </para>
 
 <programlisting>

Modified: trunk/refman-4.1/extending-mysql.xml
===================================================================
--- trunk/refman-4.1/extending-mysql.xml	2006-01-05 20:46:05 UTC (rev 694)
+++ trunk/refman-4.1/extending-mysql.xml	2006-01-05 20:47:18 UTC (rev 695)
@@ -260,12 +260,12 @@
               the generated result files, if needed, to adjust them to
               the expected output. In that case, be very careful about
               not adding or deleting any invisible characters. Make sure
-              to only change the text or delete lines. If you have
-              to insert a line, make sure that the fields are separated
-              by a hard tab, and that there is a hard tab at the end.
-              You may want to use <command>od -c</command> to make sure
-              that your text editor has not messed anything up during
-              edit. We hope that you never have to edit the output of
+              to only change the text or delete lines. If you have to
+              insert a line, make sure that the fields are separated by
+              a hard tab, and that there is a hard tab at the end. You
+              may want to use <command>od -c</command> to make sure that
+              your text editor has not messed anything up during edit.
+              We hope that you never have to edit the output of
               <command>mysqltest -r</command> as you only have to do it
               when you find a bug.
             </para>

Modified: trunk/refman-4.1/installing.xml
===================================================================
--- trunk/refman-4.1/installing.xml	2006-01-05 20:46:05 UTC (rev 694)
+++ trunk/refman-4.1/installing.xml	2006-01-05 20:47:18 UTC (rev 695)
@@ -12392,11 +12392,11 @@
             <literal>FLOAT(3,1)</literal> stores a maximum value of
             99.9. Before 4.1.2, the server allowed larger numbers to be
             stored. That is, it stored a value such as 100.0 as 100.0.
-            As of 4.1.2, the server clips 100.0 to the maximum
-            allowable value of 99.9. If you have tables that were
-            created before MySQL 4.1.2 and that contain floating-point
-            data not strictly legal for the column type, you should
-            alter the data types of those columns. For example:
+            As of 4.1.2, the server clips 100.0 to the maximum allowable
+            value of 99.9. If you have tables that were created before
+            MySQL 4.1.2 and that contain floating-point data not
+            strictly legal for the column type, you should alter the
+            data types of those columns. For example:
           </para>
 
 <programlisting>

Modified: trunk/refman-4.1/introduction.xml
===================================================================
--- trunk/refman-4.1/introduction.xml	2006-01-05 20:46:05 UTC (rev 694)
+++ trunk/refman-4.1/introduction.xml	2006-01-05 20:47:18 UTC (rev 695)
@@ -2400,12 +2400,13 @@
         </indexterm>
 
         <para>
-          Stored procedures and functions are implemented beginning with MySQL 5.0.
+          Stored procedures and functions are implemented beginning with
+          MySQL 5.0.
         </para>
 
         <para>
-          Basic trigger functionality is implemented beginning with MySQL 
-          5.0.2, with further development planned for MySQL 5.1.
+          Basic trigger functionality is implemented beginning with
+          MySQL 5.0.2, with further development planned for MySQL 5.1.
         </para>
 
       </section>
@@ -2503,8 +2504,9 @@
           <literal>MyISAM</literal> storage engine offers very fast
           performance for applications that perform only
           <literal>INSERT</literal> and <literal>SELECT</literal>
-          operations. In this case, the table has no holes in the middle and the inserts can be performed concurrently
-          with retrievals. See <xref linkend="table-locking"/>.)
+          operations. In this case, the table has no holes in the middle
+          and the inserts can be performed concurrently with retrievals.
+          See <xref linkend="table-locking"/>.)
         </para>
 
         <para>
@@ -2529,10 +2531,10 @@
           <listitem>
             <para>
               If <literal>ON DELETE</literal> is the only referential
-              integrity capability an application needs, you can achieve a similar effect as of
-              MySQL Server 4.0 by using multiple-table
-              <literal>DELETE</literal> statements to delete rows from
-              many tables with a single statement. See
+              integrity capability an application needs, you can achieve
+              a similar effect as of MySQL Server 4.0 by using
+              multiple-table <literal>DELETE</literal> statements to
+              delete rows from many tables with a single statement. See
               <xref linkend="delete"/>.
             </para>
           </listitem>
@@ -2541,17 +2543,17 @@
             <para>
               A workaround for the lack of <literal>ON DELETE</literal>
               is to add the appropriate <literal>DELETE</literal>
-              statements to your application when you delete records from
-              a table that has a foreign key. In practice, this is often
-              as quick as using foreign keys and is more portable.
+              statements to your application when you delete records
+              from a table that has a foreign key. In practice, this is
+              often as quick as using foreign keys and is more portable.
             </para>
           </listitem>
 
         </itemizedlist>
 
         <para>
-          Be aware that the use of foreign keys can sometimes
-          lead to problems:
+          Be aware that the use of foreign keys can sometimes lead to
+          problems:
         </para>
 
         <itemizedlist>
@@ -2620,8 +2622,8 @@
         </indexterm>
 
         <para>
-          Views (including updatable views) are implemented beginning with
-          MySQL Server 5.0.1.
+          Views (including updatable views) are implemented beginning
+          with MySQL Server 5.0.1.
         </para>
 
         <para>
@@ -2659,26 +2661,25 @@
           <secondary>comments</secondary>
         </indexterm>
 
-<para>
-Standard SQL uses the C syntax
-          <literal>/* this is a comment */</literal> for comments, and MySQL Server supports this syntax as well.
-MySQL also support extensions to this syntax that allow MySQL-specific SQL to be embedded in the comment, as described in
-          <xref linkend="comments"/>.
-</para>
+        <para>
+          Standard SQL uses the C syntax <literal>/* this is a comment
+          */</literal> for comments, and MySQL Server supports this
+          syntax as well. MySQL also support extensions to this syntax
+          that allow MySQL-specific SQL to be embedded in the comment,
+          as described in <xref linkend="comments"/>.
+        </para>
 
         <para>
-          Standard SQL uses
-          &lsquo;<option>--</option>&rsquo; as a start-comment sequence. MySQL
-          Server uses &lsquo;<literal>#</literal>&rsquo; as the start
-          comment character.
-          MySQL Server 3.23.3 and up also supports a variant of the
-          &lsquo;<literal>--</literal>&rsquo; comment style. That is,
-the
-          &lsquo;<literal>--</literal>&rsquo; start-comment sequence must be
-          followed by a space (or by a control character
-          such as a newline). The space is required to prevent
-          problems with automatically generated SQL queries that use constructs such as the following,
-           where we automatically
+          Standard SQL uses &lsquo;<option>--</option>&rsquo; as a
+          start-comment sequence. MySQL Server uses
+          &lsquo;<literal>#</literal>&rsquo; as the start comment
+          character. MySQL Server 3.23.3 and up also supports a variant
+          of the &lsquo;<literal>--</literal>&rsquo; comment style. That
+          is, the &lsquo;<literal>--</literal>&rsquo; start-comment
+          sequence must be followed by a space (or by a control
+          character such as a newline). The space is required to prevent
+          problems with automatically generated SQL queries that use
+          constructs such as the following, where we automatically
           insert the value of the payment for
           <literal>!payment!</literal>:
         </para>
@@ -2688,9 +2689,8 @@
 </programlisting>
 
         <para>
-          Consider about what happens if
-          <literal>payment</literal> has a negative value such as
-          <literal>-1</literal>:
+          Consider about what happens if <literal>payment</literal> has
+          a negative value such as <literal>-1</literal>:
         </para>
 
 <programlisting>
@@ -2699,11 +2699,10 @@
 
         <para>
           <literal>credit--1</literal> is a legal expression in SQL, but
-          &lsquo;<literal>--</literal>&rsquo;
-          is interpreted as the start of a
-          comment, part of the expression is discarded. The result is a
-          statement that has a completely different meaning than
-          intended:
+          &lsquo;<literal>--</literal>&rsquo; is interpreted as the
+          start of a comment, part of the expression is discarded. The
+          result is a statement that has a completely different meaning
+          than intended:
         </para>
 
 <programlisting>
@@ -2719,11 +2718,9 @@
 
         <para>
           Using our implementation of require a following space for
-          &lsquo;<literal>--</literal>&rsquo;
-to be recognized as a start-comment sequence
-in MySQL
-          Server 3.23.3 and up, <literal>credit--1</literal> is actually
-          safe.
+          &lsquo;<literal>--</literal>&rsquo; to be recognized as a
+          start-comment sequence in MySQL Server 3.23.3 and up,
+          <literal>credit--1</literal> is actually safe.
         </para>
 
         <para>
@@ -2751,7 +2748,7 @@
 </programlisting>
 
         <para>
-That is safer than executing the script in the usual way:
+          That is safer than executing the script in the usual way:
         </para>
 
 <programlisting>
@@ -2776,11 +2773,10 @@
 shell&gt; <userinput>replace " #" " --" -- text-file-with-funny-comments.sql</userinput>
 </programlisting>
 
+        <para>
+          See <xref linkend="replace-utility"/>.
+        </para>
 
-<para>
-See <xref linkend="replace-utility"/>.
-</para>
-
       </section>
 
     </section>
@@ -2818,8 +2814,8 @@
       </para>
 
       <para>
-        The following sections describe how MySQL Server handles different
-        types of constraints.
+        The following sections describe how MySQL Server handles
+        different types of constraints.
       </para>
 
       <section id="constraint-primary-key">
@@ -2858,25 +2854,22 @@
           <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"/>, and
-          <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.
-In MySQL 4.1
-          and up, you also can use the <literal>SHOW WARNINGS</literal>
-          statement.
-See <xref linkend="mysql-info"/>, and
-<xref linkend="show-warnings"/>.
+          API function. In MySQL 4.1 and up, you also can use the
+          <literal>SHOW WARNINGS</literal> statement. See
+          <xref linkend="mysql-info"/>, and
+          <xref linkend="show-warnings"/>.
         </para>
 
         <para>
-Currently,
-          only <literal>InnoDB</literal> tables
-          support foreign keys. See
+          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
           implementation in MySQL 5.2. See <xref linkend="roadmap"/>.)
@@ -2916,12 +2909,12 @@
         <para>
           Through version 4.1, MySQL is forgiving of illegal or improper
           data values and coerces them to legal values for data entry.
-          When you insert an <quote>incorrect</quote> value into a column,
-          such as a <literal>NULL</literal> into a <literal>NOT
+          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.
-The following rules describe in more detail how this works:
+          possible value</quote> instead of producing an error. The
+          following rules describe in more detail how this works:
         </para>
 
         <itemizedlist>
@@ -2930,8 +2923,8 @@
             <para>
               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, whichever is closest to the invalid value.
-              column.
+              possible value, or the largest possible value, whichever
+              is closest to the invalid value. column.
             </para>
           </listitem>
 
@@ -2951,7 +2944,9 @@
 
           <listitem>
             <para>
-Invalid values for <literal>ENUM</literal> and <literal>SET</literal> columns ae handled as described in <xref linkend="constraint-enum"/>.
+              Invalid values for <literal>ENUM</literal> and
+              <literal>SET</literal> columns ae handled as described in
+              <xref linkend="constraint-enum"/>.
             </para>
           </listitem>
 
@@ -2966,8 +2961,9 @@
               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 <quote>zero</quote> date value <literal>'0000-00-00'</literal> is
-              stored in the column instead.
+              special <quote>zero</quote> date value
+              <literal>'0000-00-00'</literal> is stored in the column
+              instead.
             </para>
           </listitem>
 
@@ -3002,12 +2998,12 @@
         </itemizedlist>
 
         <para>
-          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
-          rollback. The option of terminating the statement is not that
-          good; in this case, the update would be <quote>half
+          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 rollback. The option of terminating the statement is
+          not that good; in this case, the update would be <quote>half
           done,</quote> which is probably the worst possible scenario.
           In this case, it's better to <quote>do the best you
           can</quote> and then continue as if nothing happened.
@@ -3022,48 +3018,49 @@
         <para>
           <literal>ENUM</literal> and <literal>SET</literal> columns
           provide an efficient way to define columns that can contain
-          only a given set of values.
-See <xref linkend="enum"/>, and <xref linkend="set"/>.
-However, in MySQL 4.1 and earlier,
-          <literal>ENUM</literal> and <literal>SET</literal> columns do not
-          provide true constraints on entry of invalid data:
+          only a given set of values. See <xref linkend="enum"/>, and
+          <xref linkend="set"/>. However, in MySQL 4.1 and earlier,
+          <literal>ENUM</literal> and <literal>SET</literal> columns do
+          not provide true constraints on entry of invalid data:
         </para>
 
-<itemizedlist>
-<listitem>
-        <para>
-          <literal>ENUM</literal> columns always have a default value.
-          If you specify no default value, then it is
-          <literal>NULL</literal> for columns that can have
-          <literal>NULL</literal>, otherwise it is the first enumeration value
-          in the column definition.
-        </para>
-</listitem>
-<listitem>
-        <para>
-          If you insert an incorrect value into an
-          <literal>ENUM</literal> column or if you force a value into an
-          <literal>ENUM</literal> column with <literal>IGNORE</literal>,
-          it is set to the reserved enumeration value of
-          <literal>0</literal>, which is displayed as an empty string in
-          string context.
-        </para>
-</listitem>
-<listitem>
-        <para>
-          If you insert an incorrect value into a <literal>SET</literal>
-          column, the incorrect value is ignored. For example, if the
-          column can contain the values <literal>'a'</literal>,
-          <literal>'b'</literal>, and <literal>'c'</literal>, an attempt
-          to assign <literal>'a,x,b,y'</literal> results in a value of
-          <literal>'a,b'</literal>.
-        </para>
-</listitem>
-</itemizedlist>
+        <itemizedlist>
 
+          <listitem>
+            <para>
+              <literal>ENUM</literal> columns always have a default
+              value. If you specify no default value, then it is
+              <literal>NULL</literal> for columns that can have
+              <literal>NULL</literal>, otherwise it is the first
+              enumeration value in the column definition.
+            </para>
+          </listitem>
 
+          <listitem>
+            <para>
+              If you insert an incorrect value into an
+              <literal>ENUM</literal> column or if you force a value
+              into an <literal>ENUM</literal> column with
+              <literal>IGNORE</literal>, it is set to the reserved
+              enumeration value of <literal>0</literal>, which is
+              displayed as an empty string in string context.
+            </para>
+          </listitem>
 
+          <listitem>
+            <para>
+              If you insert an incorrect value into a
+              <literal>SET</literal> column, the incorrect value is
+              ignored. For example, if the column can contain the values
+              <literal>'a'</literal>, <literal>'b'</literal>, and
+              <literal>'c'</literal>, an attempt to assign
+              <literal>'a,x,b,y'</literal> results in a value of
+              <literal>'a,b'</literal>.
+            </para>
+          </listitem>
 
+        </itemizedlist>
+
       </section>
 
     </section>

Modified: trunk/refman-4.1/ndbcluster.xml
===================================================================
--- trunk/refman-4.1/ndbcluster.xml	2006-01-05 20:46:05 UTC (rev 694)
+++ trunk/refman-4.1/ndbcluster.xml	2006-01-05 20:47:18 UTC (rev 695)
@@ -2074,8 +2074,7 @@
 
           <listitem>
             <para>
-              <literal>[COMPUTER]</literal>: Defines the cluster
-              hosts.
+              <literal>[COMPUTER]</literal>: Defines the cluster hosts.
             </para>
           </listitem>
 
@@ -2784,8 +2783,8 @@
 
             <para>
               The memory allocated by <literal>DataMemory</literal> is
-              used to store both the actual records and indexes.
-              Each record is currently of fixed size. (Even
+              used to store both the actual records and indexes. Each
+              record is currently of fixed size. (Even
               <literal>VARCHAR</literal> columns are stored as
               fixed-width columns.) There is a 16-byte overhead on each
               record; an additional amount for each record is incurred
@@ -4275,13 +4274,13 @@
             </para>
 
             <para>
-              The UNDO index buffer is used for the updates on
-              the primary key hash index. Inserts and deletes rearrange
-              the hash index; the NDB storage engine writes UNDO log
-              records that map all physical changes to an index page so
-              that they can be undone at system restart. It also logs
-              all active insert operations for each fragment at the
-              start of a local checkpoint.
+              The UNDO index buffer is used for the updates on the
+              primary key hash index. Inserts and deletes rearrange the
+              hash index; the NDB storage engine writes UNDO log records
+              that map all physical changes to an index page so that
+              they can be undone at system restart. It also logs all
+              active insert operations for each fragment at the start of
+              a local checkpoint.
             </para>
 
             <para>
@@ -4294,10 +4293,10 @@
             <para>
               This buffer is 2MB by default. The minimum value is 1MB,
               and for most applications the minimum is sufficient. For
-              applications doing extremely large or numerous inserts
-              and deletes together with large transactions and large
-              primary keys, it may be necessary to increase the size of
-              this buffer. If this buffer is too small, the NDB storage
+              applications doing extremely large or numerous inserts and
+              deletes together with large transactions and large primary
+              keys, it may be necessary to increase the size of this
+              buffer. If this buffer is too small, the NDB storage
               engine issues internal error code 677 <literal>Index UNDO
               buffers overloaded</literal>.
             </para>
@@ -4539,9 +4538,9 @@
 
             <para>
               In creating a backup, there are two buffers used for
-              sending data to the disk. The backup data buffer is
-              used to fill in data recorded by scanning a node's tables.
-              Once this buffer has been filled to the level specified as
+              sending data to the disk. The backup data buffer is used
+              to fill in data recorded by scanning a node's tables. Once
+              this buffer has been filled to the level specified as
               <literal>BackupWriteSize</literal> (see below), the pages
               are sent to disk. While flushing data to disk, the backup
               process can continue filling this buffer until it runs out
@@ -5970,8 +5969,8 @@
                 <para>
                   As a measure of last resort when for some reason the
                   node restart or system restart repeatedly fails. In
-                  this case be aware that this node can no longer
-                  be used to restore data due to the destruction of the
+                  this case be aware that this node can no longer be
+                  used to restore data due to the destruction of the
                   datafiles.
                 </para>
               </listitem>
@@ -7870,8 +7869,8 @@
 
           <listitem>
             <para>
-              Once the backup has been aborted, the management
-              server will report <literal>Backup
+              Once the backup has been aborted, the management server
+              will report <literal>Backup
               <replaceable>backup_id</replaceable> has been aborted for
               reason <replaceable>XYZ</replaceable></literal>. This
               means that the cluster has terminated the backup and that
@@ -8300,11 +8299,11 @@
       <para>
         The next possibility uses SCI switches. An SCI switch has 8
         ports, each of which can support a ring. It is necessary to make
-        sure that different rings use different node ID spaces. In
-        a typical configuration, the first port uses node IDs below 64
-        (4 - 60), the next 64 node IDs (68 - 124) are assigned to the
-        next port, and so on, with node IDs 452 - 508 being assigned to
-        the eighth port.
+        sure that different rings use different node ID spaces. In a
+        typical configuration, the first port uses node IDs below 64 (4
+        - 60), the next 64 node IDs (68 - 124) are assigned to the next
+        port, and so on, with node IDs 452 - 508 being assigned to the
+        eighth port.
       </para>
 
       <para>
@@ -10045,10 +10044,10 @@
           &current-series;, Cluster tables (that is, tables created with
           <literal>ENGINE=NDBCLUSTER</literal>) have only fixed-width
           rows. This means that (for example) each record containing a
-          <literal>VARCHAR(255)</literal> column will require 256
-          bytes of storage for that column, regardless of the size of
-          the data stored therein. This issue is expected to be fixed in
-          a future MySQL release series.
+          <literal>VARCHAR(255)</literal> column will require 256 bytes
+          of storage for that column, regardless of the size of the data
+          stored therein. This issue is expected to be fixed in a future
+          MySQL release series.
         </para>
 
         <para>
@@ -10094,8 +10093,8 @@
 
         <para>
           Each of these commands must be run from a system shell on the
-          machine housing the affected node. You can verify the
-          cluster is running by starting the MGM management client
+          machine housing the affected node. You can verify the cluster
+          is running by starting the MGM management client
           <command>ndb_mgm</command> on the machine housing the MGM
           node.
         </para>

Modified: trunk/refman-4.1/optimization.xml
===================================================================
--- trunk/refman-4.1/optimization.xml	2006-01-05 20:46:05 UTC (rev 694)
+++ trunk/refman-4.1/optimization.xml	2006-01-05 20:47:18 UTC (rev 695)
@@ -5062,9 +5062,9 @@
 
       <para>
         MySQL keeps row data and index data in separate files. Many
-        (almost all) other database systems mix row and index data in the same
-        file. We believe that the MySQL choice is better for a very wide
-        range of modern systems.
+        (almost all) other database systems mix row and index data in
+        the same file. We believe that the MySQL choice is better for a
+        very wide range of modern systems.
       </para>
 
       <para>
@@ -6499,8 +6499,7 @@
       </para>
 
       <para>
-        MySQL uses the average value group size in the following
-        ways:
+        MySQL uses the average value group size in the following ways:
       </para>
 
       <itemizedlist>

Modified: trunk/refman-4.1/porting.xml
===================================================================
--- trunk/refman-4.1/porting.xml	2006-01-05 20:46:05 UTC (rev 694)
+++ trunk/refman-4.1/porting.xml	2006-01-05 20:47:18 UTC (rev 695)
@@ -1015,11 +1015,11 @@
           </row>
           <row>
             <entry><literal>f</literal></entry>
-            <entry>Limit debugging, tracing, and profiling to the list of named
-              functions. Note that a null list disables all functions.
-              The appropriate <literal>d</literal> or
-              <literal>t</literal> flags must still be given; this flag
-              only limits their actions if they are enabled.</entry>
+            <entry>Limit debugging, tracing, and profiling to the list of named functions.
+              Note that a null list disables all functions. The
+              appropriate <literal>d</literal> or <literal>t</literal>
+              flags must still be given; this flag only limits their
+              actions if they are enabled.</entry>
           </row>
           <row>
             <entry><literal>F</literal></entry>

Modified: trunk/refman-4.1/sql-syntax.xml
===================================================================
--- trunk/refman-4.1/sql-syntax.xml	2006-01-05 20:46:05 UTC (rev 694)
+++ trunk/refman-4.1/sql-syntax.xml	2006-01-05 20:47:18 UTC (rev 695)
@@ -12527,8 +12527,8 @@
           <para>
             The variable is a synonym for the
             <literal>LAST_INSERT_ID</literal> variable. It exists for
-            compatibility with other database systems. As of MySQL 3.23.25, you
-            can read its value with <literal>SELECT
+            compatibility with other database systems. As of MySQL
+            3.23.25, you can read its value with <literal>SELECT
             @@IDENTITY</literal>. As of MySQL 4.0.3, you can also set
             its value with <literal>SET IDENTITY</literal>.
           </para>

Modified: trunk/refman-5.0/client-side-scripts.xml
===================================================================
--- trunk/refman-5.0/client-side-scripts.xml	2006-01-05 20:46:05 UTC (rev 694)
+++ trunk/refman-5.0/client-side-scripts.xml	2006-01-05 20:47:18 UTC (rev 695)
@@ -6216,11 +6216,11 @@
               zones. (Without this option, <literal>TIMESTAMP</literal>
               columns are dumped and reloaded in the local time zones of
               the source and destination servers.)
-              <option>--tz-utc</option> also protects against
-              changes due to daylight saving time.
-              <option>--tz-utc</option> is enabled by default. To
-              disable it, use <option>--skip-tz-utc</option>. This
-              option was added in MySQL 5.0.15.
+              <option>--tz-utc</option> also protects against changes
+              due to daylight saving time. <option>--tz-utc</option> is
+              enabled by default. To disable it, use
+              <option>--skip-tz-utc</option>. This option was added in
+              MySQL 5.0.15.
             </para>
           </listitem>
 

Modified: trunk/refman-5.0/connector-j.xml
===================================================================
--- trunk/refman-5.0/connector-j.xml	2006-01-05 20:46:05 UTC (rev 694)
+++ trunk/refman-5.0/connector-j.xml	2006-01-05 20:47:18 UTC (rev 695)
@@ -1061,11 +1061,11 @@
         </para>
 
         <para>
-          If you are developing servlets or JSPs, and your
-          application server is J2EE-compliant, you can put the driver's
-          .jar file in the WEB-INF/lib subdirectory of your webapp, as
-          this is a standard location for third party class libraries in
-          J2EE web applications.
+          If you are developing servlets or JSPs, and your application
+          server is J2EE-compliant, you can put the driver's .jar file
+          in the WEB-INF/lib subdirectory of your webapp, as this is a
+          standard location for third party class libraries in J2EE web
+          applications.
         </para>
 
         <para>

Modified: trunk/refman-5.0/connector-odbc.xml
===================================================================
--- trunk/refman-5.0/connector-odbc.xml	2006-01-05 20:46:05 UTC (rev 694)
+++ trunk/refman-5.0/connector-odbc.xml	2006-01-05 20:47:18 UTC (rev 695)
@@ -4992,8 +4992,7 @@
       <para>
         Here is an excellent article from Mike Hillyer
         (<email>m.hillyer@stripped</email>); explaining how to
-        insert or fetch data from blob columns through MyODBC from
-        ADO:
+        insert or fetch data from blob columns through MyODBC from ADO:
         <ulink url="http://www.dynamergy.com/mike/articles/blobaccessvb.html">MySQL
         BLOB columns and Visual Basic 6</ulink>.
       </para>

Modified: trunk/refman-5.0/data-types.xml
===================================================================
--- trunk/refman-5.0/data-types.xml	2006-01-05 20:46:05 UTC (rev 694)
+++ trunk/refman-5.0/data-types.xml	2006-01-05 20:47:18 UTC (rev 695)
@@ -5143,12 +5143,11 @@
     </para>
 
     <para>
-      Tables created in MySQL 5.0.3 and above uses a new storage
-      format for <literal>DECIMAL</literal> columns. All basic
-      calculation (<literal>+,-,*,/</literal>) with
-      <literal>DECIMAL</literal> columns are done with precision of 65
-      decimal (base 10) digits. See
-      <xref linkend="numeric-type-overview"/>.
+      Tables created in MySQL 5.0.3 and above uses a new storage format
+      for <literal>DECIMAL</literal> columns. All basic calculation
+      (<literal>+,-,*,/</literal>) with <literal>DECIMAL</literal>
+      columns are done with precision of 65 decimal (base 10) digits.
+      See <xref linkend="numeric-type-overview"/>.
     </para>
 
     <para>

Modified: trunk/refman-5.0/database-administration.xml
===================================================================
--- trunk/refman-5.0/database-administration.xml	2006-01-05 20:46:05 UTC (rev 694)
+++ trunk/refman-5.0/database-administration.xml	2006-01-05 20:47:18 UTC (rev 695)
@@ -640,8 +640,8 @@
         started with the <option>--skip-innodb</option> or
         <option>--skip-bdb</option> options at runtime. For the
         <literal>NDB Cluster</literal> storage engine,
-        <literal>DISABLED</literal> means the server was compiled
-        with support for MySQL Cluster, but was not started with the
+        <literal>DISABLED</literal> means the server was compiled with
+        support for MySQL Cluster, but was not started with the
         <option>--ndb-cluster</option> option.
       </para>
 
@@ -18901,10 +18901,10 @@
 </programlisting>
 
         <para>
-          After executing this command, the data directory contains
-          a new binary log file,
-          <filename>gbichot2-bin.000007</filename>. The resulting
-          <filename>.sql</filename> file contains these lines:
+          After executing this command, the data directory contains a
+          new binary log file, <filename>gbichot2-bin.000007</filename>.
+          The resulting <filename>.sql</filename> file contains these
+          lines:
         </para>
 
 <programlisting>

Modified: trunk/refman-5.0/extending-mysql.xml
===================================================================
--- trunk/refman-5.0/extending-mysql.xml	2006-01-05 20:46:05 UTC (rev 694)
+++ trunk/refman-5.0/extending-mysql.xml	2006-01-05 20:47:18 UTC (rev 695)
@@ -251,12 +251,12 @@
               the generated result files, if needed, to adjust them to
               the expected output. In that case, be very careful about
               not adding or deleting any invisible characters. Make sure
-              to only change the text or delete lines. If you have
-              to insert a line, make sure that the fields are separated
-              by a hard tab, and that there is a hard tab at the end.
-              You may want to use <command>od -c</command> to make sure
-              that your text editor has not messed anything up during
-              edit. We hope that you never have to edit the output of
+              to only change the text or delete lines. If you have to
+              insert a line, make sure that the fields are separated by
+              a hard tab, and that there is a hard tab at the end. You
+              may want to use <command>od -c</command> to make sure that
+              your text editor has not messed anything up during edit.
+              We hope that you never have to edit the output of
               <command>mysqltest -r</command> as you only have to do it
               when you find a bug.
             </para>

Modified: trunk/refman-5.0/installing.xml
===================================================================
--- trunk/refman-5.0/installing.xml	2006-01-05 20:46:05 UTC (rev 694)
+++ trunk/refman-5.0/installing.xml	2006-01-05 20:47:18 UTC (rev 695)
@@ -12079,8 +12079,8 @@
             <literal>DECIMAL(3,1)</literal> stores a maximum value of
             99.9. Before MySQL 5.0.3, the server allowed larger numbers
             to be stored. That is, it stored a value such as 100.0 as
-            100.0. As of MySQL 5.0.3, the server clips 100.0 to
-            the maximum allowable value of 99.9. If you have tables that
+            100.0. As of MySQL 5.0.3, the server clips 100.0 to the
+            maximum allowable value of 99.9. If you have tables that
             were created before MySQL 5.0.3 and that contain
             floating-point data not strictly legal for the column type,
             you should alter the data types of those columns. For

Modified: trunk/refman-5.0/introduction.xml
===================================================================
--- trunk/refman-5.0/introduction.xml	2006-01-05 20:46:05 UTC (rev 694)
+++ trunk/refman-5.0/introduction.xml	2006-01-05 20:47:18 UTC (rev 695)
@@ -2033,14 +2033,14 @@
         </indexterm>
 
         <para>
-          Stored procedures and functions are implemented beginning with MySQL 5.0. See
-          <xref linkend="stored-procedures"/>.
+          Stored procedures and functions are implemented beginning with
+          MySQL 5.0. See <xref linkend="stored-procedures"/>.
         </para>
 
         <para>
-          Basic trigger functionality is implemented beginning with MySQL
-          5.0.2, with further development planned for MySQL
-          5.1. See <xref linkend="triggers"/>.
+          Basic trigger functionality is implemented beginning with
+          MySQL 5.0.2, with further development planned for MySQL 5.1.
+          See <xref linkend="triggers"/>.
         </para>
 
       </section>
@@ -2138,8 +2138,9 @@
           <literal>MyISAM</literal> storage engine offers very fast
           performance for applications that perform only
           <literal>INSERT</literal> and <literal>SELECT</literal>
-          operations. In this case, the table has no holes in the middle and the inserts can be performed concurrently
-          with retrievals. See <xref linkend="table-locking"/>.)
+          operations. In this case, the table has no holes in the middle
+          and the inserts can be performed concurrently with retrievals.
+          See <xref linkend="table-locking"/>.)
         </para>
 
         <para>
@@ -2164,10 +2165,10 @@
           <listitem>
             <para>
               If <literal>ON DELETE</literal> is the only referential
-              integrity capability an application needs, you can achieve a similar effect as of
-              MySQL Server 4.0 by using multiple-table
-              <literal>DELETE</literal> statements to delete rows from
-              many tables with a single statement. See
+              integrity capability an application needs, you can achieve
+              a similar effect as of MySQL Server 4.0 by using
+              multiple-table <literal>DELETE</literal> statements to
+              delete rows from many tables with a single statement. See
               <xref linkend="delete"/>.
             </para>
           </listitem>
@@ -2176,17 +2177,17 @@
             <para>
               A workaround for the lack of <literal>ON DELETE</literal>
               is to add the appropriate <literal>DELETE</literal>
-              statements to your application when you delete records from
-              a table that has a foreign key. In practice, this is often
-              as quick as using foreign keys and is more portable.
+              statements to your application when you delete records
+              from a table that has a foreign key. In practice, this is
+              often as quick as using foreign keys and is more portable.
             </para>
           </listitem>
 
         </itemizedlist>
 
         <para>
-          Be aware that the use of foreign keys can sometimes
-          lead to problems:
+          Be aware that the use of foreign keys can sometimes lead to
+          problems:
         </para>
 
         <itemizedlist>
@@ -2255,8 +2256,8 @@
         </indexterm>
 
         <para>
-          Views (including updatable views) are implemented beginning with
-          MySQL Server 5.0.1.  See <xref linkend="views"/>.
+          Views (including updatable views) are implemented beginning
+          with MySQL Server 5.0.1. See <xref linkend="views"/>.
         </para>
 
         <para>
@@ -2294,26 +2295,25 @@
           <secondary>comments</secondary>
         </indexterm>
 
-<para>
-Standard SQL uses the C syntax
-          <literal>/* this is a comment */</literal> for comments, and MySQL Server supports this syntax as well.
-MySQL also support extensions to this syntax that allow MySQL-specific SQL to be embedded in the comment, as described in
-          <xref linkend="comments"/>.
-</para>
+        <para>
+          Standard SQL uses the C syntax <literal>/* this is a comment
+          */</literal> for comments, and MySQL Server supports this
+          syntax as well. MySQL also support extensions to this syntax
+          that allow MySQL-specific SQL to be embedded in the comment,
+          as described in <xref linkend="comments"/>.
+        </para>
 
         <para>
-          Standard SQL uses
-          &lsquo;<option>--</option>&rsquo; as a start-comment sequence. MySQL
-          Server uses &lsquo;<literal>#</literal>&rsquo; as the start
-          comment character.
-          MySQL Server 3.23.3 and up also supports a variant of the
-          &lsquo;<literal>--</literal>&rsquo; comment style. That is,
-the
-          &lsquo;<literal>--</literal>&rsquo; start-comment sequence must be
-          followed by a space (or by a control character
-          such as a newline). The space is required to prevent
-          problems with automatically generated SQL queries that use constructs such as the following,
-           where we automatically
+          Standard SQL uses &lsquo;<option>--</option>&rsquo; as a
+          start-comment sequence. MySQL Server uses
+          &lsquo;<literal>#</literal>&rsquo; as the start comment
+          character. MySQL Server 3.23.3 and up also supports a variant
+          of the &lsquo;<literal>--</literal>&rsquo; comment style. That
+          is, the &lsquo;<literal>--</literal>&rsquo; start-comment
+          sequence must be followed by a space (or by a control
+          character such as a newline). The space is required to prevent
+          problems with automatically generated SQL queries that use
+          constructs such as the following, where we automatically
           insert the value of the payment for
           <literal>!payment!</literal>:
         </para>
@@ -2323,9 +2323,8 @@
 </programlisting>
 
         <para>
-          Consider about what happens if
-          <literal>payment</literal> has a negative value such as
-          <literal>-1</literal>:
+          Consider about what happens if <literal>payment</literal> has
+          a negative value such as <literal>-1</literal>:
         </para>
 
 <programlisting>
@@ -2334,11 +2333,10 @@
 
         <para>
           <literal>credit--1</literal> is a legal expression in SQL, but
-          &lsquo;<literal>--</literal>&rsquo;
-          is interpreted as the start of a
-          comment, part of the expression is discarded. The result is a
-          statement that has a completely different meaning than
-          intended:
+          &lsquo;<literal>--</literal>&rsquo; is interpreted as the
+          start of a comment, part of the expression is discarded. The
+          result is a statement that has a completely different meaning
+          than intended:
         </para>
 
 <programlisting>
@@ -2354,11 +2352,9 @@
 
         <para>
           Using our implementation of require a following space for
-          &lsquo;<literal>--</literal>&rsquo;
-to be recognized as a start-comment sequence
-in MySQL
-          Server 3.23.3 and up, <literal>credit--1</literal> is actually
-          safe.
+          &lsquo;<literal>--</literal>&rsquo; to be recognized as a
+          start-comment sequence in MySQL Server 3.23.3 and up,
+          <literal>credit--1</literal> is actually safe.
         </para>
 
         <para>
@@ -2386,7 +2382,7 @@
 </programlisting>
 
         <para>
-That is safer than executing the script in the usual way:
+          That is safer than executing the script in the usual way:
         </para>
 
 <programlisting>
@@ -2411,11 +2407,10 @@
 shell&gt; <userinput>replace " #" " --" -- text-file-with-funny-comments.sql</userinput>
 </programlisting>
 
+        <para>
+          See <xref linkend="replace-utility"/>.
+        </para>
 
-<para>
-See <xref linkend="replace-utility"/>.
-</para>
-
       </section>
 
     </section>
@@ -2461,19 +2456,20 @@
 
       <para>
         Beginning with MySQL 5.0.2, several SQL mode options are
-        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 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"/>.
+        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
+        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 how MySQL Server handles different
-        types of constraints.
+        The following sections describe how MySQL Server handles
+        different types of constraints.
       </para>
 
       <section id="constraint-primary-key">
@@ -2512,24 +2508,22 @@
           <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"/>, and
-          <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.
-In MySQL 4.1
-          and up, you also can use the <literal>SHOW WARNINGS</literal>
-          statement.
-See <xref linkend="mysql-info"/>, and
-<xref linkend="show-warnings"/>.
+          API function. In MySQL 4.1 and up, you also can use the
+          <literal>SHOW WARNINGS</literal> statement. See
+          <xref linkend="mysql-info"/>, and
+          <xref linkend="show-warnings"/>.
         </para>
 
         <para>
-          Currently, only <literal>InnoDB</literal> tables
-          support foreign keys. See
+          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
           implementation in MySQL 5.2. See <xref linkend="roadmap"/>.
@@ -2570,26 +2564,26 @@
           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 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.
-        <xref linkend="server-sql-mode"/>.
-</para>
+          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.
+          <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>
+          This section describes the default (forgiving) behavior of
+          MySQL, as well as the newer strict SQL mode and how it
+          differs.
         </para>
 
         <para>
-          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:
+          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>
@@ -2598,9 +2592,8 @@
             <para>
               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, whichever is
-closest to the invalid value.
-              column.
+              possible value, or the largest possible value, whichever
+              is closest to the invalid value. column.
             </para>
           </listitem>
 
@@ -2620,7 +2613,9 @@
 
           <listitem>
             <para>
-Invalid values for <literal>ENUM</literal> and <literal>SET</literal> columns ae handled as described in <xref linkend="constraint-enum"/>.
+              Invalid values for <literal>ENUM</literal> and
+              <literal>SET</literal> columns ae handled as described in
+              <xref linkend="constraint-enum"/>.
             </para>
           </listitem>
 
@@ -2635,8 +2630,9 @@
               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 <quote>zero</quote> date value <literal>'0000-00-00'</literal> is
-              stored in the column instead.
+              special <quote>zero</quote> date value
+              <literal>'0000-00-00'</literal> is stored in the column
+              instead.
             </para>
           </listitem>
 
@@ -2671,14 +2667,14 @@
         </itemizedlist>
 
         <para>
-          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
-          rollback. The option of terminating the statement is not that
-          good; in this case, the update would be <quote>half
-          done,</quote> which is probably the worst possible scenario.
-          In this case, it's better to <quote>do the best you
+          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 rollback. The option of terminating the
+          statement is not that good; in this case, the update would be
+          <quote>half done,</quote> which is probably the worst possible
+          scenario. In this case, it's better to <quote>do the best you
           can</quote> and then continue as if nothing happened.
         </para>
 
@@ -2695,8 +2691,9 @@
 </programlisting>
 
         <para>
-          <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:
+          <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>
@@ -2711,17 +2708,20 @@
 
           <listitem>
             <para>
-              For non-transactional storage engines, a statement
-              aborts if the error occurs in the first row to be inserted
-              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, 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 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.
+              For non-transactional storage engines, a statement aborts
+              if the error occurs in the first row to be inserted 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, 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 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>
 
@@ -2762,49 +2762,54 @@
         <para>
           <literal>ENUM</literal> and <literal>SET</literal> columns
           provide an efficient way to define columns that can contain
-          only a given set of values.
-See <xref linkend="enum"/>, and <xref linkend="set"/>.
-However, before MySQL 5.0.2,
-          <literal>ENUM</literal> and <literal>SET</literal> columns do not
-          provide true constraints on entry of invalid data:
+          only a given set of values. See <xref linkend="enum"/>, and
+          <xref linkend="set"/>. However, before MySQL 5.0.2,
+          <literal>ENUM</literal> and <literal>SET</literal> columns do
+          not provide true constraints on entry of invalid data:
         </para>
-<itemizedlist>
-<listitem>
-        <para>
-          <literal>ENUM</literal> columns always have a default value.
-          If you specify no default value, then it is
-          <literal>NULL</literal> for columns that can have
-          <literal>NULL</literal>, otherwise it is the first enumeration value
-          in the column definition.
-        </para>
-</listitem>
-<listitem>
-        <para>
-          If you insert an incorrect value into an
-          <literal>ENUM</literal> column or if you force a value into an
-          <literal>ENUM</literal> column with <literal>IGNORE</literal>,
-          it is set to the reserved enumeration value of
-          <literal>0</literal>, which is displayed as an empty string in
-          string context.
-        </para>
-</listitem>
-<listitem>
-        <para>
-          If you insert an incorrect value into a <literal>SET</literal>
-          column, the incorrect value is ignored. For example, if the
-          column can contain the values <literal>'a'</literal>,
-          <literal>'b'</literal>, and <literal>'c'</literal>, an attempt
-          to assign <literal>'a,x,b,y'</literal> results in a value of
-          <literal>'a,b'</literal>.
-        </para>
-</listitem>
-</itemizedlist>
 
+        <itemizedlist>
+
+          <listitem>
+            <para>
+              <literal>ENUM</literal> columns always have a default
+              value. If you specify no default value, then it is
+              <literal>NULL</literal> for columns that can have
+              <literal>NULL</literal>, otherwise it is the first
+              enumeration value in the column definition.
+            </para>
+          </listitem>
+
+          <listitem>
+            <para>
+              If you insert an incorrect value into an
+              <literal>ENUM</literal> column or if you force a value
+              into an <literal>ENUM</literal> column with
+              <literal>IGNORE</literal>, it is set to the reserved
+              enumeration value of <literal>0</literal>, which is
+              displayed as an empty string in string context.
+            </para>
+          </listitem>
+
+          <listitem>
+            <para>
+              If you insert an incorrect value into a
+              <literal>SET</literal> column, the incorrect value is
+              ignored. For example, if the column can contain the values
+              <literal>'a'</literal>, <literal>'b'</literal>, and
+              <literal>'c'</literal>, an attempt to assign
+              <literal>'a,x,b,y'</literal> results in a value of
+              <literal>'a,b'</literal>.
+            </para>
+          </listitem>
+
+        </itemizedlist>
+
         <para>
           As of MySQL 5.0.2, you can configure the server to use strict
           SQL mode. See <xref linkend="server-sql-mode"/>. With strict
-          mode enabled, the definition of a <literal>ENUM</literal>
-          or <literal>SET</literal> column does act as a constraint on
+          mode enabled, the definition of a <literal>ENUM</literal> or
+          <literal>SET</literal> column does act as a constraint on
           values entered into the column. An error occurs for values
           that do not satisfy these conditions:
         </para>
@@ -2826,11 +2831,11 @@
           <listitem>
             <para>
               A <literal>SET</literal> value must be the empty string or
-              a value consisting only of the values listed in
-              the column definition separated by commas. For a column
-              defined as <literal>SET('a','b','c')</literal>, values
-              such as <literal>'d'</literal> or
-              <literal>'a,b,c,d'</literal> are illegal and are rejected.
+              a value consisting only of the values listed in the column
+              definition separated by commas. For a column defined as
+              <literal>SET('a','b','c')</literal>, values such as
+              <literal>'d'</literal> or <literal>'a,b,c,d'</literal> are
+              illegal and are rejected.
             </para>
           </listitem>
 

Modified: trunk/refman-5.0/ndbcluster.xml
===================================================================
--- trunk/refman-5.0/ndbcluster.xml	2006-01-05 20:46:05 UTC (rev 694)
+++ trunk/refman-5.0/ndbcluster.xml	2006-01-05 20:47:18 UTC (rev 695)
@@ -2071,8 +2071,7 @@
 
           <listitem>
             <para>
-              <literal>[COMPUTER]</literal>: Defines the cluster
-              hosts.
+              <literal>[COMPUTER]</literal>: Defines the cluster hosts.
             </para>
           </listitem>
 
@@ -2786,8 +2785,8 @@
 
             <para>
               The memory allocated by <literal>DataMemory</literal> is
-              used to store both the actual records and indexes.
-              Each record is currently of fixed size. (Even
+              used to store both the actual records and indexes. Each
+              record is currently of fixed size. (Even
               <literal>VARCHAR</literal> columns are stored as
               fixed-width columns.) There is a 16-byte overhead on each
               record; an additional amount for each record is incurred
@@ -4288,13 +4287,13 @@
             </para>
 
             <para>
-              The UNDO index buffer is used for the updates on
-              the primary key hash index. Inserts and deletes rearrange
-              the hash index; the NDB storage engine writes UNDO log
-              records that map all physical changes to an index page so
-              that they can be undone at system restart. It also logs
-              all active insert operations for each fragment at the
-              start of a local checkpoint.
+              The UNDO index buffer is used for the updates on the
+              primary key hash index. Inserts and deletes rearrange the
+              hash index; the NDB storage engine writes UNDO log records
+              that map all physical changes to an index page so that
+              they can be undone at system restart. It also logs all
+              active insert operations for each fragment at the start of
+              a local checkpoint.
             </para>
 
             <para>
@@ -4307,10 +4306,10 @@
             <para>
               This buffer is 2MB by default. The minimum value is 1MB,
               and for most applications the minimum is sufficient. For
-              applications doing extremely large or numerous inserts
-              and deletes together with large transactions and large
-              primary keys, it may be necessary to increase the size of
-              this buffer. If this buffer is too small, the NDB storage
+              applications doing extremely large or numerous inserts and
+              deletes together with large transactions and large primary
+              keys, it may be necessary to increase the size of this
+              buffer. If this buffer is too small, the NDB storage
               engine issues internal error code 677 <literal>Index UNDO
               buffers overloaded</literal>.
             </para>
@@ -4552,9 +4551,9 @@
 
             <para>
               In creating a backup, there are two buffers used for
-              sending data to the disk. The backup data buffer is
-              used to fill in data recorded by scanning a node's tables.
-              Once this buffer has been filled to the level specified as
+              sending data to the disk. The backup data buffer is used
+              to fill in data recorded by scanning a node's tables. Once
+              this buffer has been filled to the level specified as
               <literal>BackupWriteSize</literal> (see below), the pages
               are sent to disk. While flushing data to disk, the backup
               process can continue filling this buffer until it runs out
@@ -5948,8 +5947,8 @@
                 <para>
                   As a measure of last resort when for some reason the
                   node restart or system restart repeatedly fails. In
-                  this case be aware that this node can no longer
-                  be used to restore data due to the destruction of the
+                  this case be aware that this node can no longer be
+                  used to restore data due to the destruction of the
                   datafiles.
                 </para>
               </listitem>
@@ -7844,8 +7843,8 @@
 
           <listitem>
             <para>
-              Once the backup has been aborted, the management
-              server will report <literal>Backup
+              Once the backup has been aborted, the management server
+              will report <literal>Backup
               <replaceable>backup_id</replaceable> has been aborted for
               reason <replaceable>XYZ</replaceable></literal>. This
               means that the cluster has terminated the backup and that
@@ -8273,11 +8272,11 @@
       <para>
         The next possibility uses SCI switches. An SCI switch has 8
         ports, each of which can support a ring. It is necessary to make
-        sure that different rings use different node ID spaces. In
-        a typical configuration, the first port uses node IDs below 64
-        (4 - 60), the next 64 node IDs (68 - 124) are assigned to the
-        next port, and so on, with node IDs 452 - 508 being assigned to
-        the eighth port.
+        sure that different rings use different node ID spaces. In a
+        typical configuration, the first port uses node IDs below 64 (4
+        - 60), the next 64 node IDs (68 - 124) are assigned to the next
+        port, and so on, with node IDs 452 - 508 being assigned to the
+        eighth port.
       </para>
 
       <para>
@@ -10331,10 +10330,10 @@
           (that is, tables created with
           <literal>ENGINE=NDBCLUSTER</literal>) have only fixed-width
           rows. This means that (for example) each record containing a
-          <literal>VARCHAR(255)</literal> column will require 256
-          bytes of storage for that column, regardless of the size of
-          the data stored therein. This issue is expected to be fixed in
-          a future MySQL release series.
+          <literal>VARCHAR(255)</literal> column will require 256 bytes
+          of storage for that column, regardless of the size of the data
+          stored therein. This issue is expected to be fixed in a future
+          MySQL release series.
         </para>
 
         <para>
@@ -10380,8 +10379,8 @@
 
         <para>
           Each of these commands must be run from a system shell on the
-          machine housing the affected node. You can verify the
-          cluster is running by starting the MGM management client
+          machine housing the affected node. You can verify the cluster
+          is running by starting the MGM management client
           <command>ndb_mgm</command> on the machine housing the MGM
           node.
         </para>

Modified: trunk/refman-5.0/optimization.xml
===================================================================
--- trunk/refman-5.0/optimization.xml	2006-01-05 20:46:05 UTC (rev 694)
+++ trunk/refman-5.0/optimization.xml	2006-01-05 20:47:18 UTC (rev 695)
@@ -6527,9 +6527,9 @@
 
       <para>
         MySQL keeps row data and index data in separate files. Many
-        (almost all) other database systems mix row and index data in the same
-        file. We believe that the MySQL choice is better for a very wide
-        range of modern systems.
+        (almost all) other database systems mix row and index data in
+        the same file. We believe that the MySQL choice is better for a
+        very wide range of modern systems.
       </para>
 
       <para>
@@ -7969,8 +7969,7 @@
       </para>
 
       <para>
-        MySQL uses the average value group size in the following
-        ways:
+        MySQL uses the average value group size in the following ways:
       </para>
 
       <itemizedlist>

Modified: trunk/refman-5.0/porting.xml
===================================================================
--- trunk/refman-5.0/porting.xml	2006-01-05 20:46:05 UTC (rev 694)
+++ trunk/refman-5.0/porting.xml	2006-01-05 20:47:18 UTC (rev 695)
@@ -1015,11 +1015,11 @@
           </row>
           <row>
             <entry><literal>f</literal></entry>
-            <entry>Limit debugging, tracing, and profiling to the list of named
-              functions. Note that a null list disables all functions.
-              The appropriate <literal>d</literal> or
-              <literal>t</literal> flags must still be given; this flag
-              only limits their actions if they are enabled.</entry>
+            <entry>Limit debugging, tracing, and profiling to the list of named functions.
+              Note that a null list disables all functions. The
+              appropriate <literal>d</literal> or <literal>t</literal>
+              flags must still be given; this flag only limits their
+              actions if they are enabled.</entry>
           </row>
           <row>
             <entry><literal>F</literal></entry>

Modified: trunk/refman-5.0/restrictions.xml
===================================================================
--- trunk/refman-5.0/restrictions.xml	2006-01-05 20:46:05 UTC (rev 694)
+++ trunk/refman-5.0/restrictions.xml	2006-01-05 20:47:18 UTC (rev 695)
@@ -73,7 +73,7 @@
       <listitem>
         <para>
           The table-maintenance statements <literal>CHECK
-            TABLES</literal> and <literal>OPTIMIZE TABLES</literal>.
+          TABLES</literal> and <literal>OPTIMIZE TABLES</literal>.
           <emphasis role="bold">Note</emphasis>: This restriction is
           lifted beginning with MySQL 5.0.17.
         </para>
@@ -736,9 +736,9 @@
       <listitem>
         <para>
           If a statement prepared by <literal>PREPARE</literal> refers
-          to a view, the view contents seen each time the statement
-          is executed later will be the contents of the view at the time
-          it was prepared. This is true even if the view definition is
+          to a view, the view contents seen each time the statement is
+          executed later will be the contents of the view at the time it
+          was prepared. This is true even if the view definition is
           changed after the statement is prepared and before it is
           executed. Example:
         </para>

Modified: trunk/refman-5.0/spatial-extensions.xml
===================================================================
--- trunk/refman-5.0/spatial-extensions.xml	2006-01-05 20:46:05 UTC (rev 694)
+++ trunk/refman-5.0/spatial-extensions.xml	2006-01-05 20:47:18 UTC (rev 695)
@@ -77,9 +77,9 @@
 
       <listitem>
         <para>
-          If you have questions or concerns about the use of the
-          spatial extensions to MySQL, you can discuss these in the GIS
-          forums: <ulink url="http://forums.mysql.com/list.php?23"/>.
+          If you have questions or concerns about the use of the spatial
+          extensions to MySQL, you can discuss these in the GIS forums:
+          <ulink url="http://forums.mysql.com/list.php?23"/>.
         </para>
       </listitem>
 

Modified: trunk/refman-5.0/sql-syntax.xml
===================================================================
--- trunk/refman-5.0/sql-syntax.xml	2006-01-05 20:46:05 UTC (rev 694)
+++ trunk/refman-5.0/sql-syntax.xml	2006-01-05 20:47:18 UTC (rev 695)
@@ -13796,9 +13796,9 @@
           <para>
             The variable is a synonym for the
             <literal>LAST_INSERT_ID</literal> variable. It exists for
-            compatibility with other database systems. You can read its value
-            with <literal>SELECT @@IDENTITY</literal>, and set it using
-            <literal>SET IDENTITY</literal>.
+            compatibility with other database systems. You can read its
+            value with <literal>SELECT @@IDENTITY</literal>, and set it
+            using <literal>SET IDENTITY</literal>.
           </para>
         </listitem>
 

Modified: trunk/refman-5.0/storage-engines.xml
===================================================================
--- trunk/refman-5.0/storage-engines.xml	2006-01-05 20:46:05 UTC (rev 694)
+++ trunk/refman-5.0/storage-engines.xml	2006-01-05 20:47:18 UTC (rev 695)
@@ -3455,8 +3455,8 @@
 
       <remark role="todo">
         Stuff we could cover: - If federated table is replicated, the
-        slave hosts must be able to use the account in the
-        CONNECTION to connect to the remote server.
+        slave hosts must be able to use the account in the CONNECTION to
+        connect to the remote server.
       </remark>
 
       <para>

Modified: trunk/refman-5.1/client-side-scripts.xml
===================================================================
--- trunk/refman-5.1/client-side-scripts.xml	2006-01-05 20:46:05 UTC (rev 694)
+++ trunk/refman-5.1/client-side-scripts.xml	2006-01-05 20:47:18 UTC (rev 695)
@@ -6249,11 +6249,11 @@
               zones. (Without this option, <literal>TIMESTAMP</literal>
               columns are dumped and reloaded in the local time zones of
               the source and destination servers.)
-              <option>--tz-utc</option> also protects against
-              changes due to daylight saving time.
-              <option>--tz-utc</option> is enabled by default. To
-              disable it, use <option>--skip-tz-utc</option>. This
-              option was added in MySQL 5.1.2.
+              <option>--tz-utc</option> also protects against changes
+              due to daylight saving time. <option>--tz-utc</option> is
+              enabled by default. To disable it, use
+              <option>--skip-tz-utc</option>. This option was added in
+              MySQL 5.1.2.
             </para>
           </listitem>
 

Modified: trunk/refman-5.1/connector-j.xml
===================================================================
--- trunk/refman-5.1/connector-j.xml	2006-01-05 20:46:05 UTC (rev 694)
+++ trunk/refman-5.1/connector-j.xml	2006-01-05 20:47:18 UTC (rev 695)
@@ -1061,11 +1061,11 @@
         </para>
 
         <para>
-          If you are developing servlets or JSPs, and your
-          application server is J2EE-compliant, you can put the driver's
-          .jar file in the WEB-INF/lib subdirectory of your webapp, as
-          this is a standard location for third party class libraries in
-          J2EE web applications.
+          If you are developing servlets or JSPs, and your application
+          server is J2EE-compliant, you can put the driver's .jar file
+          in the WEB-INF/lib subdirectory of your webapp, as this is a
+          standard location for third party class libraries in J2EE web
+          applications.
         </para>
 
         <para>

Modified: trunk/refman-5.1/connector-odbc.xml
===================================================================
--- trunk/refman-5.1/connector-odbc.xml	2006-01-05 20:46:05 UTC (rev 694)
+++ trunk/refman-5.1/connector-odbc.xml	2006-01-05 20:47:18 UTC (rev 695)
@@ -4992,8 +4992,7 @@
       <para>
         Here is an excellent article from Mike Hillyer
         (<email>m.hillyer@stripped</email>); explaining how to
-        insert or fetch data from blob columns through MyODBC from
-        ADO:
+        insert or fetch data from blob columns through MyODBC from ADO:
         <ulink url="http://www.dynamergy.com/mike/articles/blobaccessvb.html">MySQL
         BLOB columns and Visual Basic 6</ulink>.
       </para>

Modified: trunk/refman-5.1/database-administration.xml
===================================================================
--- trunk/refman-5.1/database-administration.xml	2006-01-05 20:46:05 UTC (rev 694)
+++ trunk/refman-5.1/database-administration.xml	2006-01-05 20:47:18 UTC (rev 695)
@@ -640,8 +640,8 @@
         started with the <option>--skip-innodb</option> or
         <option>--skip-bdb</option> options at runtime. For the
         <literal>NDB Cluster</literal> storage engine,
-        <literal>DISABLED</literal> means the server was compiled
-        with support for MySQL Cluster, but was not started with the
+        <literal>DISABLED</literal> means the server was compiled with
+        support for MySQL Cluster, but was not started with the
         <option>--ndb-cluster</option> option.
       </para>
 
@@ -18850,10 +18850,10 @@
 </programlisting>
 
         <para>
-          After executing this command, the data directory contains
-          a new binary log file,
-          <filename>gbichot2-bin.000007</filename>. The resulting
-          <filename>.sql</filename> file contains these lines:
+          After executing this command, the data directory contains a
+          new binary log file, <filename>gbichot2-bin.000007</filename>.
+          The resulting <filename>.sql</filename> file contains these
+          lines:
         </para>
 
 <programlisting>

Modified: trunk/refman-5.1/extending-mysql.xml
===================================================================
--- trunk/refman-5.1/extending-mysql.xml	2006-01-05 20:46:05 UTC (rev 694)
+++ trunk/refman-5.1/extending-mysql.xml	2006-01-05 20:47:18 UTC (rev 695)
@@ -251,12 +251,12 @@
               the generated result files, if needed, to adjust them to
               the expected output. In that case, be very careful about
               not adding or deleting any invisible characters. Make sure
-              to only change the text or delete lines. If you have
-              to insert a line, make sure that the fields are separated
-              by a hard tab, and that there is a hard tab at the end.
-              You may want to use <command>od -c</command> to make sure
-              that your text editor has not messed anything up during
-              edit. We hope that you never have to edit the output of
+              to only change the text or delete lines. If you have to
+              insert a line, make sure that the fields are separated by
+              a hard tab, and that there is a hard tab at the end. You
+              may want to use <command>od -c</command> to make sure that
+              your text editor has not messed anything up during edit.
+              We hope that you never have to edit the output of
               <command>mysqltest -r</command> as you only have to do it
               when you find a bug.
             </para>

Modified: trunk/refman-5.1/introduction.xml
===================================================================
--- trunk/refman-5.1/introduction.xml	2006-01-05 20:46:05 UTC (rev 694)
+++ trunk/refman-5.1/introduction.xml	2006-01-05 20:47:18 UTC (rev 695)
@@ -1792,14 +1792,14 @@
         </indexterm>
 
         <para>
-          Stored procedures and functions are implemented beginning with MySQL 5.0. See
-          <xref linkend="stored-procedures"/>.
+          Stored procedures and functions are implemented beginning with
+          MySQL 5.0. See <xref linkend="stored-procedures"/>.
         </para>
 
         <para>
-          Basic trigger functionality is implemented beginning with MySQL
-          5.0.2, with further development planned for MySQL
-          5.1. See <xref linkend="triggers"/>.
+          Basic trigger functionality is implemented beginning with
+          MySQL 5.0.2, with further development planned for MySQL 5.1.
+          See <xref linkend="triggers"/>.
         </para>
 
       </section>
@@ -1897,8 +1897,9 @@
           <literal>MyISAM</literal> storage engine offers very fast
           performance for applications that perform only
           <literal>INSERT</literal> and <literal>SELECT</literal>
-          operations. In this case, the table has no holes in the middle and the inserts can be performed concurrently
-          with retrievals. See <xref linkend="table-locking"/>.)
+          operations. In this case, the table has no holes in the middle
+          and the inserts can be performed concurrently with retrievals.
+          See <xref linkend="table-locking"/>.)
         </para>
 
         <para>
@@ -1923,10 +1924,10 @@
           <listitem>
             <para>
               If <literal>ON DELETE</literal> is the only referential
-              integrity capability an application needs, you can achieve a similar effect as of
-              MySQL Server 4.0 by using multiple-table
-              <literal>DELETE</literal> statements to delete rows from
-              many tables with a single statement. See
+              integrity capability an application needs, you can achieve
+              a similar effect as of MySQL Server 4.0 by using
+              multiple-table <literal>DELETE</literal> statements to
+              delete rows from many tables with a single statement. See
               <xref linkend="delete"/>.
             </para>
           </listitem>
@@ -1935,17 +1936,17 @@
             <para>
               A workaround for the lack of <literal>ON DELETE</literal>
               is to add the appropriate <literal>DELETE</literal>
-              statements to your application when you delete records from
-              a table that has a foreign key. In practice, this is often
-              as quick as using foreign keys and is more portable.
+              statements to your application when you delete records
+              from a table that has a foreign key. In practice, this is
+              often as quick as using foreign keys and is more portable.
             </para>
           </listitem>
 
         </itemizedlist>
 
         <para>
-          Be aware that the use of foreign keys can sometimes
-          lead to problems:
+          Be aware that the use of foreign keys can sometimes lead to
+          problems:
         </para>
 
         <itemizedlist>
@@ -2014,8 +2015,8 @@
         </indexterm>
 
         <para>
-          Views (including updatable views) are implemented beginning with
-          MySQL Server 5.0.1.  See <xref linkend="views"/>.
+          Views (including updatable views) are implemented beginning
+          with MySQL Server 5.0.1. See <xref linkend="views"/>.
         </para>
 
         <para>
@@ -2053,26 +2054,25 @@
           <secondary>comments</secondary>
         </indexterm>
 
-<para>
-Standard SQL uses the C syntax
-          <literal>/* this is a comment */</literal> for comments, and MySQL Server supports this syntax as well.
-MySQL also support extensions to this syntax that allow MySQL-specific SQL to be embedded in the comment, as described in
-          <xref linkend="comments"/>.
-</para>
+        <para>
+          Standard SQL uses the C syntax <literal>/* this is a comment
+          */</literal> for comments, and MySQL Server supports this
+          syntax as well. MySQL also support extensions to this syntax
+          that allow MySQL-specific SQL to be embedded in the comment,
+          as described in <xref linkend="comments"/>.
+        </para>
 
         <para>
-          Standard SQL uses
-          &lsquo;<option>--</option>&rsquo; as a start-comment sequence. MySQL
-          Server uses &lsquo;<literal>#</literal>&rsquo; as the start
-          comment character.
-          MySQL Server 3.23.3 and up also supports a variant of the
-          &lsquo;<literal>--</literal>&rsquo; comment style. That is,
-the
-          &lsquo;<literal>--</literal>&rsquo; start-comment sequence must be
-          followed by a space (or by a control character
-          such as a newline). The space is required to prevent
-          problems with automatically generated SQL queries that use constructs such as the following,
-           where we automatically
+          Standard SQL uses &lsquo;<option>--</option>&rsquo; as a
+          start-comment sequence. MySQL Server uses
+          &lsquo;<literal>#</literal>&rsquo; as the start comment
+          character. MySQL Server 3.23.3 and up also supports a variant
+          of the &lsquo;<literal>--</literal>&rsquo; comment style. That
+          is, the &lsquo;<literal>--</literal>&rsquo; start-comment
+          sequence must be followed by a space (or by a control
+          character such as a newline). The space is required to prevent
+          problems with automatically generated SQL queries that use
+          constructs such as the following, where we automatically
           insert the value of the payment for
           <literal>!payment!</literal>:
         </para>
@@ -2082,9 +2082,8 @@
 </programlisting>
 
         <para>
-          Consider about what happens if
-          <literal>payment</literal> has a negative value such as
-          <literal>-1</literal>:
+          Consider about what happens if <literal>payment</literal> has
+          a negative value such as <literal>-1</literal>:
         </para>
 
 <programlisting>
@@ -2093,11 +2092,10 @@
 
         <para>
           <literal>credit--1</literal> is a legal expression in SQL, but
-          &lsquo;<literal>--</literal>&rsquo;
-          is interpreted as the start of a
-          comment, part of the expression is discarded. The result is a
-          statement that has a completely different meaning than
-          intended:
+          &lsquo;<literal>--</literal>&rsquo; is interpreted as the
+          start of a comment, part of the expression is discarded. The
+          result is a statement that has a completely different meaning
+          than intended:
         </para>
 
 <programlisting>
@@ -2113,11 +2111,9 @@
 
         <para>
           Using our implementation of require a following space for
-          &lsquo;<literal>--</literal>&rsquo;
-to be recognized as a start-comment sequence
-in MySQL
-          Server 3.23.3 and up, <literal>credit--1</literal> is actually
-          safe.
+          &lsquo;<literal>--</literal>&rsquo; to be recognized as a
+          start-comment sequence in MySQL Server 3.23.3 and up,
+          <literal>credit--1</literal> is actually safe.
         </para>
 
         <para>
@@ -2145,7 +2141,7 @@
 </programlisting>
 
         <para>
-That is safer than executing the script in the usual way:
+          That is safer than executing the script in the usual way:
         </para>
 
 <programlisting>
@@ -2170,11 +2166,10 @@
 shell&gt; <userinput>replace " #" " --" -- text-file-with-funny-comments.sql</userinput>
 </programlisting>
 
+        <para>
+          See <xref linkend="replace-utility"/>.
+        </para>
 
-<para>
-See <xref linkend="replace-utility"/>.
-</para>
-
       </section>
 
     </section>
@@ -2220,19 +2215,20 @@
 
       <para>
         Several SQL mode options are 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
-         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
+        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 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 how MySQL Server handles different
-        types of constraints.
+        The following sections describe how MySQL Server handles
+        different types of constraints.
       </para>
 
       <section id="constraint-primary-key">
@@ -2271,24 +2267,22 @@
           <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"/>, and
-          <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.
-In MySQL 4.1
-          and up, you also can use the <literal>SHOW WARNINGS</literal>
-          statement.
-See <xref linkend="mysql-info"/>, and
-<xref linkend="show-warnings"/>.
+          API function. In MySQL 4.1 and up, you also can use the
+          <literal>SHOW WARNINGS</literal> statement. See
+          <xref linkend="mysql-info"/>, and
+          <xref linkend="show-warnings"/>.
         </para>
 
         <para>
-          Currently, only <literal>InnoDB</literal> tables
-          support foreign keys. See
+          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
           implementation in MySQL 5.2. See <xref linkend="roadmap"/>.
@@ -2329,26 +2323,26 @@
           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 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.
-        <xref linkend="server-sql-mode"/>.
-</para>
+          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.
+          <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>
+          This section describes the default (forgiving) behavior of
+          MySQL, as well as the newer strict SQL mode and how it
+          differs.
         </para>
 
         <para>
-          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:
+          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>
@@ -2357,9 +2351,8 @@
             <para>
               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, whichever is
-closest to the invalid value.
-              column.
+              possible value, or the largest possible value, whichever
+              is closest to the invalid value. column.
             </para>
           </listitem>
 
@@ -2379,7 +2372,9 @@
 
           <listitem>
             <para>
-Invalid values for <literal>ENUM</literal> and <literal>SET</literal> columns ae handled as described in <xref linkend="constraint-enum"/>.
+              Invalid values for <literal>ENUM</literal> and
+              <literal>SET</literal> columns ae handled as described in
+              <xref linkend="constraint-enum"/>.
             </para>
           </listitem>
 
@@ -2394,8 +2389,9 @@
               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 <quote>zero</quote> date value <literal>'0000-00-00'</literal> is
-              stored in the column instead.
+              special <quote>zero</quote> date value
+              <literal>'0000-00-00'</literal> is stored in the column
+              instead.
             </para>
           </listitem>
 
@@ -2430,14 +2426,14 @@
         </itemizedlist>
 
         <para>
-          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
-          rollback. The option of terminating the statement is not that
-          good; in this case, the update would be <quote>half
-          done,</quote> which is probably the worst possible scenario.
-          In this case, it's better to <quote>do the best you
+          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 rollback. The option of terminating the
+          statement is not that good; in this case, the update would be
+          <quote>half done,</quote> which is probably the worst possible
+          scenario. In this case, it's better to <quote>do the best you
           can</quote> and then continue as if nothing happened.
         </para>
 
@@ -2454,8 +2450,9 @@
 </programlisting>
 
         <para>
-          <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:
+          <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>
@@ -2470,17 +2467,20 @@
 
           <listitem>
             <para>
-              For non-transactional storage engines, a statement
-              aborts if the error occurs in the first row to be inserted
-              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, 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 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.
+              For non-transactional storage engines, a statement aborts
+              if the error occurs in the first row to be inserted 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, 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 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>
 
@@ -2521,49 +2521,54 @@
         <para>
           <literal>ENUM</literal> and <literal>SET</literal> columns
           provide an efficient way to define columns that can contain
-          only a given set of values.
-See <xref linkend="enum"/>, and <xref linkend="set"/>.
-However, before MySQL 5.0.2,
-          <literal>ENUM</literal> and <literal>SET</literal> columns do not
-          provide true constraints on entry of invalid data:
+          only a given set of values. See <xref linkend="enum"/>, and
+          <xref linkend="set"/>. However, before MySQL 5.0.2,
+          <literal>ENUM</literal> and <literal>SET</literal> columns do
+          not provide true constraints on entry of invalid data:
         </para>
-<itemizedlist>
-<listitem>
-        <para>
-          <literal>ENUM</literal> columns always have a default value.
-          If you specify no default value, then it is
-          <literal>NULL</literal> for columns that can have
-          <literal>NULL</literal>, otherwise it is the first enumeration value
-          in the column definition.
-        </para>
-</listitem>
-<listitem>
-        <para>
-          If you insert an incorrect value into an
-          <literal>ENUM</literal> column or if you force a value into an
-          <literal>ENUM</literal> column with <literal>IGNORE</literal>,
-          it is set to the reserved enumeration value of
-          <literal>0</literal>, which is displayed as an empty string in
-          string context.
-        </para>
-</listitem>
-<listitem>
-        <para>
-          If you insert an incorrect value into a <literal>SET</literal>
-          column, the incorrect value is ignored. For example, if the
-          column can contain the values <literal>'a'</literal>,
-          <literal>'b'</literal>, and <literal>'c'</literal>, an attempt
-          to assign <literal>'a,x,b,y'</literal> results in a value of
-          <literal>'a,b'</literal>.
-        </para>
-</listitem>
-</itemizedlist>
 
+        <itemizedlist>
+
+          <listitem>
+            <para>
+              <literal>ENUM</literal> columns always have a default
+              value. If you specify no default value, then it is
+              <literal>NULL</literal> for columns that can have
+              <literal>NULL</literal>, otherwise it is the first
+              enumeration value in the column definition.
+            </para>
+          </listitem>
+
+          <listitem>
+            <para>
+              If you insert an incorrect value into an
+              <literal>ENUM</literal> column or if you force a value
+              into an <literal>ENUM</literal> column with
+              <literal>IGNORE</literal>, it is set to the reserved
+              enumeration value of <literal>0</literal>, which is
+              displayed as an empty string in string context.
+            </para>
+          </listitem>
+
+          <listitem>
+            <para>
+              If you insert an incorrect value into a
+              <literal>SET</literal> column, the incorrect value is
+              ignored. For example, if the column can contain the values
+              <literal>'a'</literal>, <literal>'b'</literal>, and
+              <literal>'c'</literal>, an attempt to assign
+              <literal>'a,x,b,y'</literal> results in a value of
+              <literal>'a,b'</literal>.
+            </para>
+          </listitem>
+
+        </itemizedlist>
+
         <para>
           As of MySQL 5.0.2, you can configure the server to use strict
           SQL mode. See <xref linkend="server-sql-mode"/>. With strict
-          mode enabled, the definition of a <literal>ENUM</literal>
-          or <literal>SET</literal> column does act as a constraint on
+          mode enabled, the definition of a <literal>ENUM</literal> or
+          <literal>SET</literal> column does act as a constraint on
           values entered into the column. An error occurs for values
           that do not satisfy these conditions:
         </para>
@@ -2585,11 +2590,11 @@
           <listitem>
             <para>
               A <literal>SET</literal> value must be the empty string or
-              a value consisting only of the values listed in
-              the column definition separated by commas. For a column
-              defined as <literal>SET('a','b','c')</literal>, values
-              such as <literal>'d'</literal> or
-              <literal>'a,b,c,d'</literal> are illegal and are rejected.
+              a value consisting only of the values listed in the column
+              definition separated by commas. For a column defined as
+              <literal>SET('a','b','c')</literal>, values such as
+              <literal>'d'</literal> or <literal>'a,b,c,d'</literal> are
+              illegal and are rejected.
             </para>
           </listitem>
 

Modified: trunk/refman-5.1/ndbcluster.xml
===================================================================
--- trunk/refman-5.1/ndbcluster.xml	2006-01-05 20:46:05 UTC (rev 694)
+++ trunk/refman-5.1/ndbcluster.xml	2006-01-05 20:47:18 UTC (rev 695)
@@ -2071,8 +2071,7 @@
 
           <listitem>
             <para>
-              <literal>[COMPUTER]</literal>: Defines the cluster
-              hosts.
+              <literal>[COMPUTER]</literal>: Defines the cluster hosts.
             </para>
           </listitem>
 
@@ -2786,8 +2785,8 @@
 
             <para>
               The memory allocated by <literal>DataMemory</literal> is
-              used to store both the actual records and indexes.
-              Each record is currently of fixed size. (Even
+              used to store both the actual records and indexes. Each
+              record is currently of fixed size. (Even
               <literal>VARCHAR</literal> columns are stored as
               fixed-width columns.) There is a 16-byte overhead on each
               record; an additional amount for each record is incurred
@@ -4288,13 +4287,13 @@
             </para>
 
             <para>
-              The UNDO index buffer is used for the updates on
-              the primary key hash index. Inserts and deletes rearrange
-              the hash index; the NDB storage engine writes UNDO log
-              records that map all physical changes to an index page so
-              that they can be undone at system restart. It also logs
-              all active insert operations for each fragment at the
-              start of a local checkpoint.
+              The UNDO index buffer is used for the updates on the
+              primary key hash index. Inserts and deletes rearrange the
+              hash index; the NDB storage engine writes UNDO log records
+              that map all physical changes to an index page so that
+              they can be undone at system restart. It also logs all
+              active insert operations for each fragment at the start of
+              a local checkpoint.
             </para>
 
             <para>
@@ -4307,10 +4306,10 @@
             <para>
               This buffer is 2MB by default. The minimum value is 1MB,
               and for most applications the minimum is sufficient. For
-              applications doing extremely large or numerous inserts
-              and deletes together with large transactions and large
-              primary keys, it may be necessary to increase the size of
-              this buffer. If this buffer is too small, the NDB storage
+              applications doing extremely large or numerous inserts and
+              deletes together with large transactions and large primary
+              keys, it may be necessary to increase the size of this
+              buffer. If this buffer is too small, the NDB storage
               engine issues internal error code 677 <literal>Index UNDO
               buffers overloaded</literal>.
             </para>
@@ -4552,9 +4551,9 @@
 
             <para>
               In creating a backup, there are two buffers used for
-              sending data to the disk. The backup data buffer is
-              used to fill in data recorded by scanning a node's tables.
-              Once this buffer has been filled to the level specified as
+              sending data to the disk. The backup data buffer is used
+              to fill in data recorded by scanning a node's tables. Once
+              this buffer has been filled to the level specified as
               <literal>BackupWriteSize</literal> (see below), the pages
               are sent to disk. While flushing data to disk, the backup
               process can continue filling this buffer until it runs out
@@ -5948,8 +5947,8 @@
                 <para>
                   As a measure of last resort when for some reason the
                   node restart or system restart repeatedly fails. In
-                  this case be aware that this node can no longer
-                  be used to restore data due to the destruction of the
+                  this case be aware that this node can no longer be
+                  used to restore data due to the destruction of the
                   datafiles.
                 </para>
               </listitem>
@@ -7844,8 +7843,8 @@
 
           <listitem>
             <para>
-              Once the backup has been aborted, the management
-              server will report <literal>Backup
+              Once the backup has been aborted, the management server
+              will report <literal>Backup
               <replaceable>backup_id</replaceable> has been aborted for
               reason <replaceable>XYZ</replaceable></literal>. This
               means that the cluster has terminated the backup and that
@@ -9885,11 +9884,11 @@
       <para>
         The next possibility uses SCI switches. An SCI switch has 8
         ports, each of which can support a ring. It is necessary to make
-        sure that different rings use different node ID spaces. In
-        a typical configuration, the first port uses node IDs below 64
-        (4 - 60), the next 64 node IDs (68 - 124) are assigned to the
-        next port, and so on, with node IDs 452 - 508 being assigned to
-        the eighth port.
+        sure that different rings use different node ID spaces. In a
+        typical configuration, the first port uses node IDs below 64 (4
+        - 60), the next 64 node IDs (68 - 124) are assigned to the next
+        port, and so on, with node IDs 452 - 508 being assigned to the
+        eighth port.
       </para>
 
       <para>
@@ -11911,10 +11910,10 @@
           (that is, tables created with
           <literal>ENGINE=NDBCLUSTER</literal>) have only fixed-width
           rows. This means that (for example) each record containing a
-          <literal>VARCHAR(255)</literal> column will require 256
-          bytes of storage for that column, regardless of the size of
-          the data stored therein. This issue is expected to be fixed in
-          a future MySQL release series.
+          <literal>VARCHAR(255)</literal> column will require 256 bytes
+          of storage for that column, regardless of the size of the data
+          stored therein. This issue is expected to be fixed in a future
+          MySQL release series.
         </para>
 
         <para>
@@ -11960,8 +11959,8 @@
 
         <para>
           Each of these commands must be run from a system shell on the
-          machine housing the affected node. You can verify the
-          cluster is running by starting the MGM management client
+          machine housing the affected node. You can verify the cluster
+          is running by starting the MGM management client
           <command>ndb_mgm</command> on the machine housing the MGM
           node.
         </para>

Modified: trunk/refman-5.1/optimization.xml
===================================================================
--- trunk/refman-5.1/optimization.xml	2006-01-05 20:46:05 UTC (rev 694)
+++ trunk/refman-5.1/optimization.xml	2006-01-05 20:47:18 UTC (rev 695)
@@ -6497,9 +6497,9 @@
 
       <para>
         MySQL keeps row data and index data in separate files. Many
-        (almost all) other database systems mix row and index data in the same
-        file. We believe that the MySQL choice is better for a very wide
-        range of modern systems.
+        (almost all) other database systems mix row and index data in
+        the same file. We believe that the MySQL choice is better for a
+        very wide range of modern systems.
       </para>
 
       <para>
@@ -7938,8 +7938,7 @@
       </para>
 
       <para>
-        MySQL uses the average value group size in the following
-        ways:
+        MySQL uses the average value group size in the following ways:
       </para>
 
       <itemizedlist>

Modified: trunk/refman-5.1/porting.xml
===================================================================
--- trunk/refman-5.1/porting.xml	2006-01-05 20:46:05 UTC (rev 694)
+++ trunk/refman-5.1/porting.xml	2006-01-05 20:47:18 UTC (rev 695)
@@ -1015,11 +1015,11 @@
           </row>
           <row>
             <entry><literal>f</literal></entry>
-            <entry>Limit debugging, tracing, and profiling to the list of named
-              functions. Note that a null list disables all functions.
-              The appropriate <literal>d</literal> or
-              <literal>t</literal> flags must still be given; this flag
-              only limits their actions if they are enabled.</entry>
+            <entry>Limit debugging, tracing, and profiling to the list of named functions.
+              Note that a null list disables all functions. The
+              appropriate <literal>d</literal> or <literal>t</literal>
+              flags must still be given; this flag only limits their
+              actions if they are enabled.</entry>
           </row>
           <row>
             <entry><literal>F</literal></entry>

Modified: trunk/refman-5.1/replication.xml
===================================================================
--- trunk/refman-5.1/replication.xml	2006-01-05 20:46:05 UTC (rev 694)
+++ trunk/refman-5.1/replication.xml	2006-01-05 20:47:18 UTC (rev 695)
@@ -236,7 +236,7 @@
   <section id="replication-row-based">
 
     <title>&title-replication-row-based;</title>
-    
+
     <para>
       <remark role="todo">
         [SH] Provide a definition of row-based replication.
@@ -258,7 +258,7 @@
     <para>
       If you're building MySQL from source, it must be compiled with the
       <option>--with-row-based-replication</option> switch to
-      <command>configure</command> in order to enable row-based 
+      <command>configure</command> in order to enable row-based
       replication.
     </para>
 
@@ -296,13 +296,13 @@
 </programlisting>
     </para>
 -->
-    
+
     <para>
       If you want to switch back to statement-based replication, restart
       the server without the <literal>--binlog-format=row</literal>
       option (statement-based replication is the default) or by
-      specifiying <option>--binlog-format=statement</option>
-      explicitly.
+      specifiying <option>--binlog-format=statement</option> explicitly.
+
 <!--  Remove comment when WL#2712 is implemented         
       Without restarting the server, you can set the dynamic
       server system variable, like this:
@@ -319,7 +319,7 @@
 -->
     </para>
 
-      <para>
+    <para>
 <!--  Remove comment when WL#2712 is implemented         
       The dynamic server system variable even allows you to set
       replication logging on a per-connection basis. To enable
@@ -336,6 +336,7 @@
 mysql> <userinput>SET LOCAL BINLOG_FORMAT = 1;</userinput>
 </programlisting>
 -->
+
       Here are two reasons why you would want to set replication logging
       on a per-connection basis:
 
@@ -4277,16 +4278,14 @@
 
         <listitem>
           <para>
-            Not all <literal>UPDATE</literal> statements 
-            can be replicated:
-            Any non-deterministic behavior, for example when
-            using random functions in an SQL statement, is 
-            hard to replicate when using statement-based
-            replication.
-            When using a non-deterministic user-defined function (UDF), 
-            it is not possible to replicate the result using 
-            statement-based replication, while row-based replication 
-            will just replicate the value returned by the UDF. 
+            Not all <literal>UPDATE</literal> statements can be
+            replicated: Any non-deterministic behavior, for example when
+            using random functions in an SQL statement, is hard to
+            replicate when using statement-based replication. When using
+            a non-deterministic user-defined function (UDF), it is not
+            possible to replicate the result using statement-based
+            replication, while row-based replication will just replicate
+            the value returned by the UDF.
           </para>
         </listitem>
 
@@ -4407,18 +4406,16 @@
         <listitem>
           <para>
             Everything can be replicated; safest form of replication.
-            Note that currently, DDL (data definition language) 
-            statements such as <literal>CREATE TABLE</literal>
-            are replicated using statement-based replication,
-            while DML (data manipulation language) statements,
-            as well as <literal>GRANT</literal> and 
-            <literal>REVOKE</literal> statements, are replicated
-            using row-based-replication.
-            For statements like 
-            <literal>CREATE &hellip; SELECT</literal>, a 
-            <literal>CREATE</literal> statement is generated from the 
-            table definition and replicated statement-based, while 
-            the row insertions are replicated row-based.
+            Note that currently, DDL (data definition language)
+            statements such as <literal>CREATE TABLE</literal> are
+            replicated using statement-based replication, while DML
+            (data manipulation language) statements, as well as
+            <literal>GRANT</literal> and <literal>REVOKE</literal>
+            statements, are replicated using row-based-replication. For
+            statements like <literal>CREATE &hellip; SELECT</literal>, a
+            <literal>CREATE</literal> statement is generated from the
+            table definition and replicated statement-based, while the
+            row insertions are replicated row-based.
           </para>
         </listitem>
 
@@ -4429,10 +4426,10 @@
             systems).
           </para>
         </listitem>
-        
+
         <listitem>
           <para>
-            In many cases, faster to apply data on the slave on tables 
+            In many cases, faster to apply data on the slave on tables
             with primary keys.
           </para>
         </listitem>
@@ -4509,18 +4506,18 @@
         <listitem>
           <para>
             When using row-based replication to replicate a statement
-            (for example, an <literal>UPDATE</literal> or 
-            <literal>DELETE</literal> statement), each changed row has 
-            to be written to the binary log. In contrast, when using 
-            statement-based replication only the statement is written 
-            to the binary log. If the statement changes a lot of rows, 
-            row-based replication may write significantly more data to 
-            the binary log. In these cases the binary log will be locked 
-            for longer times to write the data, which may cause 
+            (for example, an <literal>UPDATE</literal> or
+            <literal>DELETE</literal> statement), each changed row has
+            to be written to the binary log. In contrast, when using
+            statement-based replication only the statement is written to
+            the binary log. If the statement changes a lot of rows,
+            row-based replication may write significantly more data to
+            the binary log. In these cases the binary log will be locked
+            for longer times to write the data, which may cause
             concurrency problems.
           </para>
         </listitem>
-        
+
         <listitem>
           <para>
             Deterministic UDFs that generate big

Modified: trunk/refman-5.1/restrictions.xml
===================================================================
--- trunk/refman-5.1/restrictions.xml	2006-01-05 20:46:05 UTC (rev 694)
+++ trunk/refman-5.1/restrictions.xml	2006-01-05 20:47:18 UTC (rev 695)
@@ -712,9 +712,9 @@
       <listitem>
         <para>
           If a statement prepared by <literal>PREPARE</literal> refers
-          to a view, the view contents seen each time the statement
-          is executed later will be the contents of the view at the time
-          it was prepared. This is true even if the view definition is
+          to a view, the view contents seen each time the statement is
+          executed later will be the contents of the view at the time it
+          was prepared. This is true even if the view definition is
           changed after the statement is prepared and before it is
           executed. Example:
         </para>

Modified: trunk/refman-5.1/spatial-extensions.xml
===================================================================
--- trunk/refman-5.1/spatial-extensions.xml	2006-01-05 20:46:05 UTC (rev 694)
+++ trunk/refman-5.1/spatial-extensions.xml	2006-01-05 20:47:18 UTC (rev 695)
@@ -77,9 +77,9 @@
 
       <listitem>
         <para>
-          If you have questions or concerns about the use of the
-          spatial extensions to MySQL, you can discuss these in the GIS
-          forums: <ulink url="http://forums.mysql.com/list.php?23"/>.
+          If you have questions or concerns about the use of the spatial
+          extensions to MySQL, you can discuss these in the GIS forums:
+          <ulink url="http://forums.mysql.com/list.php?23"/>.
         </para>
       </listitem>
 

Modified: trunk/refman-5.1/sql-syntax.xml
===================================================================
--- trunk/refman-5.1/sql-syntax.xml	2006-01-05 20:46:05 UTC (rev 694)
+++ trunk/refman-5.1/sql-syntax.xml	2006-01-05 20:47:18 UTC (rev 695)
@@ -14276,9 +14276,9 @@
           <para>
             The variable is a synonym for the
             <literal>LAST_INSERT_ID</literal> variable. It exists for
-            compatibility with other database systems. You can read its value
-            with <literal>SELECT @@IDENTITY</literal>, and set it using
-            <literal>SET IDENTITY</literal>.
+            compatibility with other database systems. You can read its
+            value with <literal>SELECT @@IDENTITY</literal>, and set it
+            using <literal>SET IDENTITY</literal>.
           </para>
         </listitem>
 

Modified: trunk/refman-5.1/storage-engines.xml
===================================================================
--- trunk/refman-5.1/storage-engines.xml	2006-01-05 20:46:05 UTC (rev 694)
+++ trunk/refman-5.1/storage-engines.xml	2006-01-05 20:47:18 UTC (rev 695)
@@ -3478,8 +3478,8 @@
 
       <remark role="todo">
         Stuff we could cover: - If federated table is replicated, the
-        slave hosts must be able to use the account in the
-        CONNECTION to connect to the remote server.
+        slave hosts must be able to use the account in the CONNECTION to
+        connect to the remote server.
       </remark>
 
       <para>

Modified: trunk/refman-common/news-4.0.xml
===================================================================
--- trunk/refman-common/news-4.0.xml	2006-01-05 20:46:05 UTC (rev 694)
+++ trunk/refman-common/news-4.0.xml	2006-01-05 20:47:18 UTC (rev 695)
@@ -133,9 +133,9 @@
     <remark role="note">
       References to bug numbers should be written after the sentence
       describing the bugfix, like this: This sentence describes the fix.
-      (Bug #nnnn) It is not necessary to state that the bug was
-      fixed, since "Bugs fixed" already implies this. Use the past tense
-      in describing the bug.
+      (Bug #nnnn) It is not necessary to state that the bug was fixed,
+      since "Bugs fixed" already implies this. Use the past tense in
+      describing the bug.
     </remark>
 
     <para>
@@ -281,9 +281,9 @@
     <remark role="note">
       References to bug numbers should be written after the sentence
       describing the bugfix, like this: This sentence describes the fix.
-      (Bug #nnnn) It is not necessary to state that the bug was
-      fixed, since "Bugs fixed" already implies this. Use the past tense
-      in describing the bug.
+      (Bug #nnnn) It is not necessary to state that the bug was fixed,
+      since "Bugs fixed" already implies this. Use the past tense in
+      describing the bug.
     </remark>
 
     <para>
@@ -382,9 +382,9 @@
     <remark role="note">
       References to bug numbers should be written after the sentence
       describing the bugfix, like this: This sentence describes the fix.
-      (Bug #nnnn) It is not necessary to state that the bug was
-      fixed, since "Bugs fixed" already implies this. Use the past tense
-      in describing the bug.
+      (Bug #nnnn) It is not necessary to state that the bug was fixed,
+      since "Bugs fixed" already implies this. Use the past tense in
+      describing the bug.
     </remark>
 
     <para>

Modified: trunk/refman-common/news-4.1.xml
===================================================================
--- trunk/refman-common/news-4.1.xml	2006-01-05 20:46:05 UTC (rev 694)
+++ trunk/refman-common/news-4.1.xml	2006-01-05 20:47:18 UTC (rev 695)
@@ -183,11 +183,12 @@
       <listitem>
         <para>
           Issuing a <literal>DROP USER</literal> command could cause
-          some users to encounter a <literal><replaceable>hostname</replaceable> is not allowed to connect to this MySQL
-            server</literal> error. (Bug #15775)
+          some users to encounter a
+          <literal><replaceable>hostname</replaceable> is not allowed to
+          connect to this MySQL server</literal> error. (Bug #15775)
         </para>
       </listitem>
-      
+
       <listitem>
         <para>
           <literal>Access Denied</literal> error could be erroneously
@@ -195,7 +196,7 @@
           (Bug #7209)
         </para>
       </listitem>
-      
+
       <listitem>
         <para>
           Symbolic links did not funciton properly on Windows platforms.
@@ -1483,8 +1484,8 @@
         <para>
           If a <literal>DROP DATABASE</literal> fails on a master server
           due to the presence of a non-database file in the database
-          directory, the master have the database tables deleted,
-          but not the slaves. To deal with failed database drops, we now
+          directory, the master have the database tables deleted, but
+          not the slaves. To deal with failed database drops, we now
           write <literal>DROP TABLE</literal> statements to the binary
           log for the tables so that they are dropped on slaves. (Bug
           #4680)
@@ -8035,11 +8036,11 @@
           <literal>FLOAT(3,1)</literal> stores a maximum value of 99.9.
           Previously, the server allowed larger numbers to be stored.
           That is, it stored a value such as 100.0 as 100.0. Now the
-          server clips 100.0 to the maximum allowable value of
-          99.9. If you have tables that were created before MySQL 4.1.2
-          and that contain floating-point data not strictly legal for
-          the column type, you should alter the data types of those
-          columns. For example:
+          server clips 100.0 to the maximum allowable value of 99.9. If
+          you have tables that were created before MySQL 4.1.2 and that
+          contain floating-point data not strictly legal for the column
+          type, you should alter the data types of those columns. For
+          example:
         </para>
 
 <programlisting>

Modified: trunk/refman-common/news-5.0.xml
===================================================================
--- trunk/refman-common/news-5.0.xml	2006-01-05 20:46:05 UTC (rev 694)
+++ trunk/refman-common/news-5.0.xml	2006-01-05 20:47:18 UTC (rev 695)
@@ -204,22 +204,23 @@
     </para>
 
     <itemizedlist>
-      
+
       <listitem>
         <para>
           Issuing a <literal>DROP USER</literal> command could cause
-          some users to encounter a <literal><replaceable>hostname</replaceable> is not allowed to connect to this MySQL
-            server</literal> error. (Bug #15775)
+          some users to encounter a
+          <literal><replaceable>hostname</replaceable> is not allowed to
+          connect to this MySQL server</literal> error. (Bug #15775)
         </para>
       </listitem>
-      
+
       <listitem>
         <para>
           Setting <literal>innodb_log_file_size</literal> to a value
           greater than 4G crashed the server. (Bug #15108)
         </para>
       </listitem>
-      
+
       <listitem>
         <para>
           A <literal>SELECT</literal> of a stored function that
@@ -227,10 +228,12 @@
           crash the server. (Bug #15533)
         </para>
       </listitem>
-      
+
       <listitem>
-        <para>Tarball install package was missing a proper
-          <filename>fill_help_tables.sql</filename> file. (Bug #15151)</para>
+        <para>
+          Tarball install package was missing a proper
+          <filename>fill_help_tables.sql</filename> file. (Bug #15151)
+        </para>
       </listitem>
 
     </itemizedlist>
@@ -730,8 +733,8 @@
 
       <listitem>
         <para>
-          Revised table locking to allow proper assessment of
-          view security. (Bug #11555)
+          Revised table locking to allow proper assessment of view
+          security. (Bug #11555)
         </para>
       </listitem>
 
@@ -2432,9 +2435,9 @@
     <remark role="note">
       References to bug numbers should be written after the sentence
       describing the bugfix, like this: This sentence describes the fix.
-      (Bug #nnnn) It is not necessary to state that the bug was
-      fixed, since "Bugs fixed" already implies this. Use the past tense
-      in describing the bug.
+      (Bug #nnnn) It is not necessary to state that the bug was fixed,
+      since "Bugs fixed" already implies this. Use the past tense in
+      describing the bug.
     </remark>
 
     <para>
@@ -3979,8 +3982,8 @@
         <para>
           If a <literal>DROP DATABASE</literal> fails on a master server
           due to the presence of a non-database file in the database
-          directory, the master have the database tables deleted,
-          but not the slaves. To deal with failed database drops, we now
+          directory, the master have the database tables deleted, but
+          not the slaves. To deal with failed database drops, we now
           write <literal>DROP TABLE</literal> statements to the binary
           log for the tables so that they are dropped on slaves. (Bug
           #4680)
@@ -6600,9 +6603,9 @@
     <remark role="note">
       References to bug numbers should be written after the sentence
       describing the bugfix, like this: This sentence describes the fix.
-      (Bug #nnnn) It is not necessary to state that the bug was
-      fixed, since "Bugs fixed" already implies this. Use the past tense
-      in describing the bug.
+      (Bug #nnnn) It is not necessary to state that the bug was fixed,
+      since "Bugs fixed" already implies this. Use the past tense in
+      describing the bug.
     </remark>
 
     <para>
@@ -8811,11 +8814,11 @@
           <literal>DECIMAL(3,1)</literal> stores a maximum value of
           99.9. Previously, the server allowed larger numbers to be
           stored. That is, it stored a value such as 100.0 as 100.0. Now
-          the server clips 100.0 to the maximum allowable value of
-          99.9. If you have tables that were created before MySQL 5.0.3
-          and that contain floating-point data not strictly legal for
-          the column type, you should alter the data types of those
-          columns. For example:
+          the server clips 100.0 to the maximum allowable value of 99.9.
+          If you have tables that were created before MySQL 5.0.3 and
+          that contain floating-point data not strictly legal for the
+          column type, you should alter the data types of those columns.
+          For example:
         </para>
 
 <programlisting>

Modified: trunk/refman-common/news-5.1.xml
===================================================================
--- trunk/refman-common/news-5.1.xml	2006-01-05 20:46:05 UTC (rev 694)
+++ trunk/refman-common/news-5.1.xml	2006-01-05 20:47:18 UTC (rev 695)
@@ -44,9 +44,9 @@
     <remark role="note">
       References to bug numbers should be written after the sentence
       describing the bugfix, like this: This sentence describes the fix.
-      (Bug #nnnn) It is not necessary to state that the bug was
-      fixed, since "Bugs fixed" already implies this. Use the past tense
-      in describing the bug.
+      (Bug #nnnn) It is not necessary to state that the bug was fixed,
+      since "Bugs fixed" already implies this. Use the past tense in
+      describing the bug.
     </remark>
 
     <para>
@@ -96,11 +96,12 @@
       <listitem>
         <para>
           Issuing a <literal>DROP USER</literal> command could cause
-          some users to encounter a <literal><replaceable>hostname</replaceable> is not allowed to connect to this MySQL
-            server</literal> error. (Bug #15775)
+          some users to encounter a
+          <literal><replaceable>hostname</replaceable> is not allowed to
+          connect to this MySQL server</literal> error. (Bug #15775)
         </para>
       </listitem>
-      
+
       <listitem>
         <para>
           The <option>--plugin_dir</option> option was not working. Also
@@ -108,7 +109,7 @@
           #16068)
         </para>
       </listitem>
-      
+
       <listitem>
         <para>
           Attempting to insert into a table partitioned by
@@ -133,9 +134,9 @@
     <remark role="note">
       References to bug numbers should be written after the sentence
       describing the bugfix, like this: This sentence describes the fix.
-      (Bug #nnnn) It is not necessary to state that the bug was
-      fixed, since "Bugs fixed" already implies this. Use the past tense
-      in describing the bug.
+      (Bug #nnnn) It is not necessary to state that the bug was fixed,
+      since "Bugs fixed" already implies this. Use the past tense in
+      describing the bug.
     </remark>
 
     <para>
@@ -418,9 +419,9 @@
     <remark role="note">
       References to bug numbers should be written after the sentence
       describing the bugfix, like this: This sentence describes the fix.
-      (Bug #nnnn) It is not necessary to state that the bug was
-      fixed, since "Bugs fixed" already implies this. Use the past tense
-      in describing the bug.
+      (Bug #nnnn) It is not necessary to state that the bug was fixed,
+      since "Bugs fixed" already implies this. Use the past tense in
+      describing the bug.
     </remark>
 
     <para>
@@ -594,9 +595,9 @@
     <remark role="note">
       References to bug numbers should be written after the sentence
       describing the bugfix, like this: This sentence describes the fix.
-      (Bug #nnnn) It is not necessary to state that the bug was
-      fixed, since "Bugs fixed" already implies this. Use the past tense
-      in describing the bug.
+      (Bug #nnnn) It is not necessary to state that the bug was fixed,
+      since "Bugs fixed" already implies this. Use the past tense in
+      describing the bug.
     </remark>
 
     <para>
@@ -668,9 +669,9 @@
     <remark role="note">
       References to bug numbers should be written after the sentence
       describing the bugfix, like this: This sentence describes the fix.
-      (Bug #nnnn) It is not necessary to state that the bug was
-      fixed, since "Bugs fixed" already implies this. Use the past tense
-      in describing the bug.
+      (Bug #nnnn) It is not necessary to state that the bug was fixed,
+      since "Bugs fixed" already implies this. Use the past tense in
+      describing the bug.
     </remark>
 
     <para>

Thread
svn commit - mysqldoc@docsrva: r695 - in trunk: . refman-4.1 refman-5.0 refman-5.1 refman-commonpaul5 Jan