List:Commits« Previous MessageNext Message »
From:paul Date:January 12 2006 7:15pm
Subject:svn commit - mysqldoc@docsrva: r780 - in trunk: . refman-4.1 refman-5.0 refman-5.1
View as plain text  
Author: paul
Date: 2006-01-12 20:15:52 +0100 (Thu, 12 Jan 2006)
New Revision: 780

Log:
 r6122@frost:  paul | 2006-01-12 13:14:42 -0600
 General revisions.


Modified:
   trunk/
   trunk/refman-4.1/functions.xml
   trunk/refman-4.1/innodb.xml
   trunk/refman-4.1/introduction.xml
   trunk/refman-4.1/ndbcluster.xml
   trunk/refman-4.1/storage-engines.xml
   trunk/refman-5.0/database-administration.xml
   trunk/refman-5.0/functions.xml
   trunk/refman-5.0/innodb.xml
   trunk/refman-5.0/ndbcluster.xml
   trunk/refman-5.0/storage-engines.xml
   trunk/refman-5.1/database-administration.xml
   trunk/refman-5.1/functions.xml
   trunk/refman-5.1/innodb.xml
   trunk/refman-5.1/ndbcluster.xml
   trunk/refman-5.1/partitioning.xml
   trunk/refman-5.1/storage-engines.xml


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

Modified: trunk/refman-4.1/functions.xml
===================================================================
--- trunk/refman-4.1/functions.xml	2006-01-12 18:19:12 UTC (rev 779)
+++ trunk/refman-4.1/functions.xml	2006-01-12 19:15:52 UTC (rev 780)
@@ -14085,9 +14085,9 @@
           <para>
             You can set a maximum allowed length with the
             <literal>group_concat_max_len</literal> system variable.
-            (The default value is 1024.)
-            The syntax to do this at runtime is as follows, where
-            <replaceable>val</replaceable> is an unsigned integer:
+            (The default value is 1024.) The syntax to do this at
+            runtime is as follows, where <replaceable>val</replaceable>
+            is an unsigned integer:
           </para>
 
 <programlisting>

Modified: trunk/refman-4.1/innodb.xml
===================================================================
--- trunk/refman-4.1/innodb.xml	2006-01-12 18:19:12 UTC (rev 779)
+++ trunk/refman-4.1/innodb.xml	2006-01-12 19:15:52 UTC (rev 780)
@@ -1870,8 +1870,7 @@
 
     <para>
       To create an <literal>InnoDB</literal> table, you must specify an
-      <literal>ENGINE = InnoDB</literal> option
-in the <literal>CREATE
+      <literal>ENGINE = InnoDB</literal> option in the <literal>CREATE
       TABLE</literal> statement:
     </para>
 
@@ -2843,7 +2842,7 @@
         writes SQL statements that modify data. A transaction that fails
         (for example, because of a foreign key violation, or because it
         is is rolled back) is not written to the binary log, so it is
-        not sent to slaves.
+        not sent to slaves. See <xref linkend="commit"/>.
       </para>
 
     </section>

Modified: trunk/refman-4.1/introduction.xml
===================================================================
--- trunk/refman-4.1/introduction.xml	2006-01-12 18:19:12 UTC (rev 779)
+++ trunk/refman-4.1/introduction.xml	2006-01-12 19:15:52 UTC (rev 780)
@@ -823,7 +823,7 @@
                   <listitem>
                     <para>
                       The <literal>CSV</literal> storage engine stores
-                      data in text files using comma-separated-values
+                      data in text files using comma-separated values
                       format. See <xref linkend="csv-storage-engine"/>.
                     </para>
                   </listitem>

Modified: trunk/refman-4.1/ndbcluster.xml
===================================================================
--- trunk/refman-4.1/ndbcluster.xml	2006-01-12 18:19:12 UTC (rev 779)
+++ trunk/refman-4.1/ndbcluster.xml	2006-01-12 19:15:52 UTC (rev 780)
@@ -4299,7 +4299,7 @@
             <para>
               Reads and updates set lock bits and update a header in the
               hash index entry. These changes are handled by the
-              page-writing algorithm to insure that these operations
+              page-writing algorithm to ensure that these operations
               need no UNDO logging.
             </para>
 
@@ -4877,7 +4877,7 @@
               <literal>1</literal>/<literal>0</literal>) parameter, and
               is disabled by default. When it is enabled, checksums for
               all messages are calculated before they placed in the send
-              buffer. This feature insures that messages are not
+              buffer. This feature ensures that messages are not
               corrupted while waiting in the send buffer, or by the
               transport mechanism.
             </para>

Modified: trunk/refman-4.1/storage-engines.xml
===================================================================
--- trunk/refman-4.1/storage-engines.xml	2006-01-12 18:19:12 UTC (rev 779)
+++ trunk/refman-4.1/storage-engines.xml	2006-01-12 19:15:52 UTC (rev 780)
@@ -218,7 +218,7 @@
       <para>
         The <literal>CSV</literal> storage engine was added in MySQL
         4.1.4. This engine stores data in text files using
-        comma-separated-values format.
+        comma-separated values format.
       </para>
     </listitem>
 
@@ -239,8 +239,8 @@
   </para>
 
   <para>
-    When you create a new table, you can tell MySQL what type of table
-    to create by adding an <literal>ENGINE</literal> or
+    When you create a new table, you can specify which storage engine to
+    use by adding an <literal>ENGINE</literal> or
     <literal>TYPE</literal> table option to the <literal>CREATE
     TABLE</literal> statement:
   </para>
@@ -278,9 +278,9 @@
 
   <para>
     When MySQL is installed on Windows using the MySQL Configuration
-    Wizard, the <literal>InnoDB</literal> storage engine is the default
-    instead of <literal>MyISAM</literal>. See
-    <xref linkend="mysql-config-wizard-introduction"/>.
+    Wizard, the <literal>InnoDB</literal> storage engine can be selected
+    as the default instead of <literal>MyISAM</literal>. See
+    <xref linkend="mysql-config-wizard-database-usage"/>.
   </para>
 
   <para>
@@ -311,33 +311,37 @@
 
   <para>
     If you try to use a storage engine that is not compiled in or that
-    is compiled in but deactivated, MySQL instead creates a table of
-    type <literal>MyISAM</literal>. This behavior is convenient when you
-    want to copy tables between MySQL servers that support different
-    storage engines. (For example, in a replication setup, perhaps your
-    master server supports transactional storage engines for increased
-    safety, but the slave servers use only non-transactional storage
-    engines for greater speed.)
+    is compiled in but deactivated, MySQL instead creates a table using
+    the default storage engine, usually <literal>MyISAM)</literal>.
+    (Before MySQL, <literal>MyISAM</literal> is always used for
+    unavailable storage engines.) type <literal>MyISAM</literal>. This
+    behavior is convenient when you want to copy tables between MySQL
+    servers that support different storage engines. (For example, in a
+    replication setup, perhaps your master server supports transactional
+    storage engines for increased safety, but the slave servers use only
+    non-transactional storage engines for greater speed.)
   </para>
 
   <para>
-    This automatic substitution of the <literal>MyISAM</literal> storage
-    engine when an unavailable engine is specified can be confusing for
-    new MySQL users. In MySQL 4.1, a warning is generated when a storage
-    engine is automatically changed.
+    This automatic substitution of the default storage engine for
+    unavailable engines can be confusing for new MySQL users. In MySQL
+    4.1, a warning is generated when a storage engine is automatically
+    changed.
   </para>
 
   <para>
-    MySQL always creates an <filename>.frm</filename> file to hold the
-    table and column definitions. The table's index and data may be
-    stored in one or more other files, depending on the storage engine.
-    The server creates the <filename>.frm</filename> file above the
-    storage engine level. Individual storage engines create any
-    additional files required for the tables that they manage.
+    For new tables, MySQL always creates an <filename>.frm</filename>
+    file to hold the table and column definitions. The table's index and
+    data may be stored in one or more other files, depending on the
+    storage engine. The server creates the <filename>.frm</filename>
+    file above the storage engine level. Individual storage engines
+    create any additional files required for the tables that they
+    manage.
   </para>
 
   <para>
-    A database may contain tables of different types.
+    A database may contain tables of different types. That is, tables
+    need not all be created with the same storage engine.
   </para>
 
   <para>
@@ -388,10 +392,15 @@
   </itemizedlist>
 
   <para>
-    Although MySQL supports several transaction-safe storage engines,
+    You can combine transaction-safe and non-transaction-safe tables in
+    the same statements to get the best of both worlds. However,
+    although MySQL supports several transaction-safe storage engines,
     for best results, you should not mix different storage engines
-    within a transaction. For information about the problems that can
-    occur if you do this, see <xref linkend="commit"/>.
+    within a transaction with autocommit disabled. For example, if you
+    do this, changes to non-transaction-safe tables still are committed
+    immediately and cannot be rolled back. For information about this
+    and other problems that can occur in transactions that use mixed
+    storage engines, see <xref linkend="commit"/>.
   </para>
 
   <para>
@@ -429,14 +438,6 @@
 
   </itemizedlist>
 
-  <para>
-    You can combine transaction-safe and non-transaction-safe tables in
-    the same statements to get the best of both worlds. However, within
-    a transaction with autocommit disabled, changes to
-    non-transaction-safe tables still are committed immediately and
-    cannot be rolled back.
-  </para>
-
   <section id="myisam-storage-engine">
 
     <title>&title-myisam-storage-engine;</title>
@@ -490,16 +491,19 @@
     <para>
       Normally, the <literal>ENGINE</literal> or <literal>TYPE</literal>
       option is unnecessary; <literal>MyISAM</literal> is the default
-      storage engine unless the default has been changed.
+      storage engine unless the default has been changed. To ensure that
+      <literal>MyISAM</literal> is used in situations where the default
+      might have been changed, specify the storage engine explicitly.
     </para>
 
     <para>
       You can check or repair <literal>MyISAM</literal> tables with the
-      <command>myisamchk</command> utility. See
-      <xref linkend="crash-recovery"/>. You can also compress
+      <command>mysqlcheck</command> client or
+      <command>myisamchk</command> utility. You can also compress
       <literal>MyISAM</literal> tables with
       <command>myisampack</command> to take up much less space. See
-      <xref linkend="myisampack"/>.
+      <xref linkend="mysqlcheck"/>, <xref linkend="crash-recovery"/>,
+      and <xref linkend="myisampack"/>.
     </para>
 
     <para>
@@ -514,11 +518,10 @@
         <para>
           All data values are stored with the low byte first. This makes
           the data machine and operating system independent. The only
-          requirement for binary portability is that the machine uses
-          two's-complement signed integers (as every machine for the
-          last 20 years has) and IEEE floating-point format (also
-          totally dominant among mainstream machines). The only area of
-          machines that may not support binary compatibility are
+          requirements for binary portability are that the machine uses
+          two's-complement signed integers and IEEE floating-point
+          format. These requirements are widely used among mainstream
+          machines. Binary compatibility might not be applicable to
           embedded systems, which sometimes have peculiar processors.
         </para>
 
@@ -598,10 +601,10 @@
 
       <listitem>
         <para>
-          When records are inserted in sorted order (as when you are
-          using an <literal>AUTO_INCREMENT</literal> column), the index
-          tree is split so that the high node only contains one key.
-          This improves space utilization in the index tree.
+          When rows are inserted in sorted order (as when you are using
+          an <literal>AUTO_INCREMENT</literal> column), the index tree
+          is split so that the high node only contains one key. This
+          improves space utilization in the index tree.
         </para>
       </listitem>
 
@@ -709,7 +712,7 @@
       <listitem>
         <para>
           Tables with <literal>VARCHAR</literal> may have fixed or
-          dynamic record length.
+          dynamic row length.
         </para>
       </listitem>
 
@@ -1013,7 +1016,7 @@
           can be found on disk: When looking up a row based on a row
           number in the index, multiply the row number by the row
           length. Also, when scanning a table, it is very easy to read a
-          constant number of records with each disk read operation.
+          constant number of rows with each disk read operation.
         </para>
 
         <para>
@@ -1021,14 +1024,14 @@
           MySQL server is writing to a fixed-format
           <literal>MyISAM</literal> file. In this case,
           <command>myisamchk</command> can easily determine where each
-          row starts and ends, so it can usually reclaim all records
-          except the partially written one. Note that
-          <literal>MyISAM</literal> table indexes can always be
-          reconstructed based on the data rows.
+          row starts and ends, so it can usually reclaim all rows except
+          the partially written one. Note that <literal>MyISAM</literal>
+          table indexes can always be reconstructed based on the data
+          rows.
         </para>
 
         <para>
-          General characteristics of static format tables:
+          Static-format tables have these characteristics:
         </para>
 
         <itemizedlist>
@@ -1056,7 +1059,7 @@
 
           <listitem>
             <para>
-              Easy to reconstruct after a crash, because records are
+              Easy to reconstruct after a crash, because rows are
               located in fixed positions.
             </para>
           </listitem>
@@ -1064,8 +1067,8 @@
           <listitem>
             <para>
               Reorganization is unnecessary unless you delete a huge
-              number of records and want to return free disk space to
-              the operating system. To do this, use <literal>OPTIMIZE
+              number of rows and want to return free disk space to the
+              operating system. To do this, use <literal>OPTIMIZE
               TABLE</literal> or <command>myisamchk -r</command>.
             </para>
           </listitem>
@@ -1104,9 +1107,9 @@
 
         <para>
           This format is a little more complex because each row has a
-          header that indicates how long it is. One record can also end
-          up at more than one location when it is made longer as a
-          result of an update.
+          header that indicates how long it is. One row can also end up
+          at more than one location when it is made longer as a result
+          of an update.
         </para>
 
         <indexterm>
@@ -1124,7 +1127,7 @@
         </para>
 
         <para>
-          General characteristics of dynamic-format tables:
+          Dynamic-format tables have these characteristics:
         </para>
 
         <itemizedlist>
@@ -1138,7 +1141,7 @@
 
           <listitem>
             <para>
-              Each record is preceded by a bitmap that indicates which
+              Each row is preceded by a bitmap that indicates which
               columns contain the empty string (for string columns) or
               zero (for numeric columns). Note that this does not
               include columns that contain <literal>NULL</literal>
@@ -1159,30 +1162,29 @@
 
           <listitem>
             <para>
-              Each record uses only as much space as is required.
-              However, if a record becomes larger, it is split into as
-              many pieces as are required, resulting in record
-              fragmentation. For example, if you update a row with
-              information that extends the row length, the row becomes
-              fragmented. In this case, you may have to run
-              <literal>OPTIMIZE TABLE</literal> or <command>myisamchk
-              -r</command> from time to time to improve performance. Use
-              <command>myisamchk -ei</command> to obtain table
-              statistics.
+              Each row uses only as much space as is required. However,
+              if a row becomes larger, it is split into as many pieces
+              as are required, resulting in row fragmentation. For
+              example, if you update a row with information that extends
+              the row length, the row becomes fragmented. In this case,
+              you may have to run <literal>OPTIMIZE TABLE</literal> or
+              <command>myisamchk -r</command> from time to time to
+              improve performance. Use <command>myisamchk -ei</command>
+              to obtain table statistics.
             </para>
           </listitem>
 
           <listitem>
             <para>
               More difficult than static-format tables to reconstruct
-              after a crash, because a record may be fragmented into
-              many pieces and a link (fragment) may be missing.
+              after a crash, because a row may be fragmented into many
+              pieces and a link (fragment) may be missing.
             </para>
           </listitem>
 
           <listitem>
             <para>
-              The expected row length for dynamic-sized records is
+              The expected row length for dynamic-sized rows is
               calculated using the following expression:
             </para>
 
@@ -1196,10 +1198,10 @@
 </programlisting>
 
             <para>
-              There is a penalty of 6 bytes for each link. A dynamic
-              record is linked whenever an update causes an enlargement
-              of the record. Each new link is at least 20 bytes, so the
-              next enlargement probably goes in the same link. If not,
+              There is a penalty of 6 bytes for each link. A dynamic row
+              is linked whenever an update causes an enlargement of the
+              row. Each new link is at least 20 bytes, so the next
+              enlargement probably goes in the same link. If not,
               another link is created. You can find the number of links
               using <command>myisamchk -ed</command>. All links may be
               removed with <command>myisamchk -r</command>.
@@ -1267,10 +1269,10 @@
 
           <listitem>
             <para>
-              Each record is compressed separately, so there is very
-              little access overhead. The header for a record takes up 1
-              to 3 bytes depending on the biggest record in the table.
-              Each column is compressed differently. There is usually a
+              Each row is compressed separately, so there is very little
+              access overhead. The header for a row takes up 1 to 3
+              bytes depending on the biggest row in the table. Each
+              column is compressed differently. There is usually a
               different Huffman tree for each column. Some of the
               compression types are:
             </para>
@@ -1326,7 +1328,7 @@
 
           <listitem>
             <para>
-              Can handle fixed-length or dynamic-length records.
+              Can handle fixed-length or dynamic-length rows.
             </para>
           </listitem>
 
@@ -1677,8 +1679,8 @@
       <literal>LAST</literal> to cause inserts to be made in the first
       or last table, respectively. If you do not specify an
       <literal>INSERT_METHOD</literal> option or if you specify it with
-      a value of <literal>NO</literal>, attempts to insert records into
-      the <literal>MERGE</literal> table result in an error.
+      a value of <literal>NO</literal>, attempts to insert rows into the
+      <literal>MERGE</literal> table result in an error.
     </para>
 
     <para>
@@ -2030,9 +2032,9 @@
         <listitem>
           <para>
             When you create a <literal>MERGE</literal> table, there is
-            no check to insure that the underlying tables exist and have
+            no check to ensure that the underlying tables exist and have
             identical structures. When the <literal>MERGE</literal>
-            table is used, MySQL checks that the record length for all
+            table is used, MySQL checks that the row length for all
             mapped tables is equal, but this is not foolproof. If you
             create a <literal>MERGE</literal> table from dissimilar
             <literal>MyISAM</literal> tables, you are very likely to run
@@ -2264,7 +2266,7 @@
 
       <listitem>
         <para>
-          <literal>MEMORY</literal> tables use a fixed record length
+          <literal>MEMORY</literal> tables use a fixed row length
           format.
         </para>
       </listitem>
@@ -3401,8 +3403,8 @@
     </para>
 
     <para>
-      <emphasis role="bold">Storage:</emphasis> Records are compressed
-      as they are inserted. The <literal>ARCHIVE</literal> engine uses
+      <emphasis role="bold">Storage:</emphasis> Rows are compressed as
+      they are inserted. The <literal>ARCHIVE</literal> engine uses
       <ulink url="http://www.zlib.net/">zlib</ulink> lossless data
       compression. Use of <literal>OPTIMIZE TABLE</literal> can analyze
       the table and pack it into a smaller format (for a reason to use
@@ -3437,8 +3439,8 @@
     </itemizedlist>
 
     <para>
-      <emphasis role="bold">Retrieval</emphasis>: On retrieval, records
-      are uncompressed on demand; there is no row cache. A
+      <emphasis role="bold">Retrieval</emphasis>: On retrieval, rows are
+      uncompressed on demand; there is no row cache. A
       <literal>SELECT</literal> operation performs a complete table
       scan: When a <literal>SELECT</literal> occurs, it finds out how
       many rows are currently available and reads that number of rows.
@@ -3481,8 +3483,8 @@
 
     <para>
       The <literal>CSV</literal> storage engine was added in MySQL
-      4.1.4. This engine stores data in text files using
-      comma-separated-values format.
+      4.1.4. This engine stores data in text files using comma-separated
+      values format.
     </para>
 
     <para>

Modified: trunk/refman-5.0/database-administration.xml
===================================================================
--- trunk/refman-5.0/database-administration.xml	2006-01-12 18:19:12 UTC (rev 779)
+++ trunk/refman-5.0/database-administration.xml	2006-01-12 19:15:52 UTC (rev 780)
@@ -23652,8 +23652,9 @@
         In MySQL &current-series;'s slow query log, slow queries that do
         not use indexes are logged as well as those that do. To prevent
         queries that do not use indexes from being logged in the slow
-        query log, use the <option>--log-queries-not-using-indexes</option> option.
-        See <xref linkend="server-options"/>.
+        query log, use the
+        <option>--log-queries-not-using-indexes</option> option. See
+        <xref linkend="server-options"/>.
       </para>
 
       <para>

Modified: trunk/refman-5.0/functions.xml
===================================================================
--- trunk/refman-5.0/functions.xml	2006-01-12 18:19:12 UTC (rev 779)
+++ trunk/refman-5.0/functions.xml	2006-01-12 19:15:52 UTC (rev 780)
@@ -14150,9 +14150,9 @@
           <para>
             You can set a maximum allowed length with the
             <literal>group_concat_max_len</literal> system variable.
-            (The default value is 1024.)
-            The syntax to do this at runtime is as follows, where
-            <replaceable>val</replaceable> is an unsigned integer:
+            (The default value is 1024.) The syntax to do this at
+            runtime is as follows, where <replaceable>val</replaceable>
+            is an unsigned integer:
           </para>
 
 <programlisting>

Modified: trunk/refman-5.0/innodb.xml
===================================================================
--- trunk/refman-5.0/innodb.xml	2006-01-12 18:19:12 UTC (rev 779)
+++ trunk/refman-5.0/innodb.xml	2006-01-12 19:15:52 UTC (rev 780)
@@ -1920,8 +1920,7 @@
 
     <para>
       To create an <literal>InnoDB</literal> table, you must specify an
-      <literal>ENGINE = InnoDB</literal> option
-in the <literal>CREATE
+      <literal>ENGINE = InnoDB</literal> option in the <literal>CREATE
       TABLE</literal> statement:
     </para>
 
@@ -2819,7 +2818,7 @@
         writes SQL statements that modify data. A transaction that fails
         (for example, because of a foreign key violation, or because it
         is is rolled back) is not written to the binary log, so it is
-        not sent to slaves.
+        not sent to slaves. See <xref linkend="commit"/>.
       </para>
 
     </section>

Modified: trunk/refman-5.0/ndbcluster.xml
===================================================================
--- trunk/refman-5.0/ndbcluster.xml	2006-01-12 18:19:12 UTC (rev 779)
+++ trunk/refman-5.0/ndbcluster.xml	2006-01-12 19:15:52 UTC (rev 780)
@@ -4312,7 +4312,7 @@
             <para>
               Reads and updates set lock bits and update a header in the
               hash index entry. These changes are handled by the
-              page-writing algorithm to insure that these operations
+              page-writing algorithm to ensure that these operations
               need no UNDO logging.
             </para>
 
@@ -4890,7 +4890,7 @@
               <literal>1</literal>/<literal>0</literal>) parameter, and
               is disabled by default. When it is enabled, checksums for
               all messages are calculated before they placed in the send
-              buffer. This feature insures that messages are not
+              buffer. This feature ensures that messages are not
               corrupted while waiting in the send buffer, or by the
               transport mechanism.
             </para>

Modified: trunk/refman-5.0/storage-engines.xml
===================================================================
--- trunk/refman-5.0/storage-engines.xml	2006-01-12 18:19:12 UTC (rev 779)
+++ trunk/refman-5.0/storage-engines.xml	2006-01-12 19:15:52 UTC (rev 780)
@@ -175,7 +175,7 @@
 
       <para>
         <emphasis role="bold">Note</emphasis>: The
-        <literal>MEMORY</literal> storage engine was formerly known as
+        <literal>MEMORY</literal> storage engine formerly was known as
         the <literal>HEAP</literal> engine.
       </para>
     </listitem>
@@ -227,7 +227,7 @@
     <listitem>
       <para>
         The <literal>CSV</literal> storage engine stores data in text
-        files using comma-separated-values format.
+        files using comma-separated values format.
       </para>
     </listitem>
 
@@ -241,8 +241,8 @@
     <listitem>
       <para>
         The <literal>FEDERATED</literal> storage engine was added in
-        MySQL 5.0.3. This engine stores data in a remote database. In
-        this release, it works with MySQL only, using the MySQL C Client
+        MySQL 5.0.3. This engine stores data in a remote database.
+        Currently, it works with MySQL only, using the MySQL C Client
         API. In future releases, we intend to enable it to connect to
         other data sources using other drivers or client connection
         methods.
@@ -258,8 +258,8 @@
   </para>
 
   <para>
-    When you create a new table, you can tell MySQL what type of table
-    to create by adding an <literal>ENGINE</literal> or
+    When you create a new table, you can specify which storage engine to
+    use by adding an <literal>ENGINE</literal> or
     <literal>TYPE</literal> table option to the <literal>CREATE
     TABLE</literal> statement:
   </para>
@@ -296,9 +296,9 @@
 
   <para>
     When MySQL is installed on Windows using the MySQL Configuration
-    Wizard, the <literal>InnoDB</literal> storage engine is the default
-    instead of <literal>MyISAM</literal>. See
-    <xref linkend="mysql-config-wizard-introduction"/>.
+    Wizard, the <literal>InnoDB</literal> storage engine can be selected
+    as the default instead of <literal>MyISAM</literal>. See
+    <xref linkend="mysql-config-wizard-database-usage"/>.
   </para>
 
   <para>
@@ -329,33 +329,34 @@
 
   <para>
     If you try to use a storage engine that is not compiled in or that
-    is compiled in but deactivated, MySQL instead creates a table of
-    type <literal>MyISAM</literal>. This behavior is convenient when you
-    want to copy tables between MySQL servers that support different
-    storage engines. (For example, in a replication setup, perhaps your
-    master server supports transactional storage engines for increased
-    safety, but the slave servers use only non-transactional storage
-    engines for greater speed.)
+    is compiled in but deactivated, MySQL instead creates a table using
+    the default storage engine, usually <literal>MyISAM</literal>. This
+    behavior is convenient when you want to copy tables between MySQL
+    servers that support different storage engines. (For example, in a
+    replication setup, perhaps your master server supports transactional
+    storage engines for increased safety, but the slave servers use only
+    non-transactional storage engines for greater speed.)
   </para>
 
   <para>
-    This automatic substitution of the <literal>MyISAM</literal> storage
-    engine when an unavailable engine is specified can be confusing for
-    new MySQL users. A warning is generated whenever a storage engine is
-    automatically changed.
+    This automatic substitution of the default storage engine for
+    unavailable engines can be confusing for new MySQL users. A warning
+    is generated whenever a storage engine is automatically changed.
   </para>
 
   <para>
-    MySQL always creates an <filename>.frm</filename> file to hold the
-    table and column definitions. The table's index and data may be
-    stored in one or more other files, depending on the storage engine.
-    The server creates the <filename>.frm</filename> file above the
-    storage engine level. Individual storage engines create any
-    additional files required for the tables that they manage.
+    For new tables, MySQL always creates an <filename>.frm</filename>
+    file to hold the table and column definitions. The table's index and
+    data may be stored in one or more other files, depending on the
+    storage engine. The server creates the <filename>.frm</filename>
+    file above the storage engine level. Individual storage engines
+    create any additional files required for the tables that they
+    manage.
   </para>
 
   <para>
-    A database may contain tables of different types.
+    A database may contain tables of different types. That is, tables
+    need not all be created with the same storage engine.
   </para>
 
   <para>
@@ -406,18 +407,18 @@
   </itemizedlist>
 
   <para>
-    Although MySQL supports several transaction-safe storage engines,
+    You can combine transaction-safe and non-transaction-safe tables in
+    the same statements to get the best of both worlds. However,
+    although MySQL supports several transaction-safe storage engines,
     for best results, you should not mix different storage engines
-    within a transaction. For information about the problems that can
-    occur if you do this, see <xref linkend="commit"/>.
+    within a transaction with autocommit disabled. For example, if you
+    do this, changes to non-transaction-safe tables still are committed
+    immediately and cannot be rolled back. For information about this
+    and other problems that can occur in transactions that use mixed
+    storage engines, see <xref linkend="commit"/>.
   </para>
 
   <para>
-    <literal>InnoDB</literal> uses default configuration values if you
-    specify none. See <xref linkend="innodb-configuration"/>.
-  </para>
-
-  <para>
     Non-transaction-safe tables have several advantages of their own,
     all of which occur because there is no transaction overhead:
   </para>
@@ -444,14 +445,6 @@
 
   </itemizedlist>
 
-  <para>
-    You can combine transaction-safe and non-transaction-safe tables in
-    the same statements to get the best of both worlds. However, within
-    a transaction with autocommit disabled, changes to
-    non-transaction-safe tables still are committed immediately and
-    cannot be rolled back.
-  </para>
-
   <section id="myisam-storage-engine">
 
     <title>&title-myisam-storage-engine;</title>
@@ -504,23 +497,27 @@
     </para>
 
     <para>
-      Normally, the <literal>ENGINE</literal> option is unnecessary;
-      <literal>MyISAM</literal> is the default storage engine unless the
-      default has been changed.
+      Normally, it is unnecesary to use <literal>ENGINE</literal> to
+      specify the <literal>MyISAM</literal> storage engine.
+      <literal>MyISAM</literal> is the default engine unless the default
+      has been changed. To ensure that <literal>MyISAM</literal> is used
+      in situations where the default might have been changed, include
+      the <literal>ENGINE</literal> option explicitly.
     </para>
 
     <para>
       You can check or repair <literal>MyISAM</literal> tables with the
-      <command>myisamchk</command> utility. See
-      <xref linkend="crash-recovery"/>. You can also compress
+      <command>mysqlcheck</command> client or
+      <command>myisamchk</command> utility. You can also compress
       <literal>MyISAM</literal> tables with
       <command>myisampack</command> to take up much less space. See
-      <xref linkend="myisampack"/>.
+      <xref linkend="mysqlcheck"/>, <xref linkend="crash-recovery"/>,
+      and <xref linkend="myisampack"/>.
     </para>
 
     <para>
-      The following are some characteristics of the
-      <literal>MyISAM</literal> storage engine:
+      <literal>MyISAM</literal> tables have the following
+      characteristics:
     </para>
 
     <itemizedlist>
@@ -529,11 +526,10 @@
         <para>
           All data values are stored with the low byte first. This makes
           the data machine and operating system independent. The only
-          requirement for binary portability is that the machine uses
-          two's-complement signed integers (as every machine for the
-          last 20 years has) and IEEE floating-point format (also
-          totally dominant among mainstream machines). The only area of
-          machines that may not support binary compatibility are
+          requirements for binary portability are that the machine uses
+          two's-complement signed integers and IEEE floating-point
+          format. These requirements are widely used among mainstream
+          machines. Binary compatibility might not be applicable to
           embedded systems, which sometimes have peculiar processors.
         </para>
 
@@ -610,10 +606,10 @@
 
       <listitem>
         <para>
-          When records are inserted in sorted order (as when you are
-          using an <literal>AUTO_INCREMENT</literal> column), the index
-          tree is split so that the high node only contains one key.
-          This improves space utilization in the index tree.
+          When rows are inserted in sorted order (as when you are using
+          an <literal>AUTO_INCREMENT</literal> column), the index tree
+          is split so that the high node only contains one key. This
+          improves space utilization in the index tree.
         </para>
       </listitem>
 
@@ -718,7 +714,7 @@
       <listitem>
         <para>
           Tables with <literal>VARCHAR</literal> may have fixed or
-          dynamic record length.
+          dynamic row length.
         </para>
       </listitem>
 
@@ -1037,7 +1033,7 @@
           can be found on disk: When looking up a row based on a row
           number in the index, multiply the row number by the row
           length. Also, when scanning a table, it is very easy to read a
-          constant number of records with each disk read operation.
+          constant number of rows with each disk read operation.
         </para>
 
         <para>
@@ -1045,14 +1041,14 @@
           MySQL server is writing to a fixed-format
           <literal>MyISAM</literal> file. In this case,
           <command>myisamchk</command> can easily determine where each
-          row starts and ends, so it can usually reclaim all records
-          except the partially written one. Note that
-          <literal>MyISAM</literal> table indexes can always be
-          reconstructed based on the data rows.
+          row starts and ends, so it can usually reclaim all rows except
+          the partially written one. Note that <literal>MyISAM</literal>
+          table indexes can always be reconstructed based on the data
+          rows.
         </para>
 
         <para>
-          General characteristics of static format tables:
+          Static-format tables have these characteristics:
         </para>
 
         <itemizedlist>
@@ -1080,7 +1076,7 @@
 
           <listitem>
             <para>
-              Easy to reconstruct after a crash, because records are
+              Easy to reconstruct after a crash, because rows are
               located in fixed positions.
             </para>
           </listitem>
@@ -1088,8 +1084,8 @@
           <listitem>
             <para>
               Reorganization is unnecessary unless you delete a huge
-              number of records and want to return free disk space to
-              the operating system. To do this, use <literal>OPTIMIZE
+              number of rows and want to return free disk space to the
+              operating system. To do this, use <literal>OPTIMIZE
               TABLE</literal> or <command>myisamchk -r</command>.
             </para>
           </listitem>
@@ -1128,9 +1124,9 @@
 
         <para>
           This format is a little more complex because each row has a
-          header that indicates how long it is. One record can also end
-          up at more than one location when it is made longer as a
-          result of an update.
+          header that indicates how long it is. One row can also end up
+          at more than one location when it is made longer as a result
+          of an update.
         </para>
 
         <indexterm>
@@ -1148,7 +1144,7 @@
         </para>
 
         <para>
-          General characteristics of dynamic-format tables:
+          Dynamic-format tables have these characteristics:
         </para>
 
         <itemizedlist>
@@ -1162,7 +1158,7 @@
 
           <listitem>
             <para>
-              Each record is preceded by a bitmap that indicates which
+              Each row is preceded by a bitmap that indicates which
               columns contain the empty string (for string columns) or
               zero (for numeric columns). Note that this does not
               include columns that contain <literal>NULL</literal>
@@ -1183,30 +1179,29 @@
 
           <listitem>
             <para>
-              Each record uses only as much space as is required.
-              However, if a record becomes larger, it is split into as
-              many pieces as are required, resulting in record
-              fragmentation. For example, if you update a row with
-              information that extends the row length, the row becomes
-              fragmented. In this case, you may have to run
-              <literal>OPTIMIZE TABLE</literal> or <command>myisamchk
-              -r</command> from time to time to improve performance. Use
-              <command>myisamchk -ei</command> to obtain table
-              statistics.
+              Each row uses only as much space as is required. However,
+              if a row becomes larger, it is split into as many pieces
+              as are required, resulting in row fragmentation. For
+              example, if you update a row with information that extends
+              the row length, the row becomes fragmented. In this case,
+              you may have to run <literal>OPTIMIZE TABLE</literal> or
+              <command>myisamchk -r</command> from time to time to
+              improve performance. Use <command>myisamchk -ei</command>
+              to obtain table statistics.
             </para>
           </listitem>
 
           <listitem>
             <para>
               More difficult than static-format tables to reconstruct
-              after a crash, because a record may be fragmented into
-              many pieces and a link (fragment) may be missing.
+              after a crash, because a row may be fragmented into many
+              pieces and a link (fragment) may be missing.
             </para>
           </listitem>
 
           <listitem>
             <para>
-              The expected row length for dynamic-sized records is
+              The expected row length for dynamic-sized rows is
               calculated using the following expression:
             </para>
 
@@ -1220,10 +1215,10 @@
 </programlisting>
 
             <para>
-              There is a penalty of 6 bytes for each link. A dynamic
-              record is linked whenever an update causes an enlargement
-              of the record. Each new link is at least 20 bytes, so the
-              next enlargement probably goes in the same link. If not,
+              There is a penalty of 6 bytes for each link. A dynamic row
+              is linked whenever an update causes an enlargement of the
+              row. Each new link is at least 20 bytes, so the next
+              enlargement probably goes in the same link. If not,
               another link is created. You can find the number of links
               using <command>myisamchk -ed</command>. All links may be
               removed with <command>myisamchk -r</command>.
@@ -1283,10 +1278,10 @@
 
           <listitem>
             <para>
-              Each record is compressed separately, so there is very
-              little access overhead. The header for a record takes up 1
-              to 3 bytes depending on the biggest record in the table.
-              Each column is compressed differently. There is usually a
+              Each row is compressed separately, so there is very little
+              access overhead. The header for a row takes up 1 to 3
+              bytes depending on the biggest row in the table. Each
+              column is compressed differently. There is usually a
               different Huffman tree for each column. Some of the
               compression types are:
             </para>
@@ -1342,7 +1337,7 @@
 
           <listitem>
             <para>
-              Can handle fixed-length or dynamic-length records.
+              Can handle fixed-length or dynamic-length rows.
             </para>
           </listitem>
 
@@ -1687,8 +1682,8 @@
       <literal>LAST</literal> to cause inserts to be made in the first
       or last table, respectively. If you do not specify an
       <literal>INSERT_METHOD</literal> option or if you specify it with
-      a value of <literal>NO</literal>, attempts to insert records into
-      the <literal>MERGE</literal> table result in an error.
+      a value of <literal>NO</literal>, attempts to insert rows into the
+      <literal>MERGE</literal> table result in an error.
     </para>
 
     <para>
@@ -2008,9 +2003,9 @@
         <listitem>
           <para>
             When you create a <literal>MERGE</literal> table, there is
-            no check to insure that the underlying tables exist and have
+            no check to ensure that the underlying tables exist and have
             identical structures. When the <literal>MERGE</literal>
-            table is used, MySQL checks that the record length for all
+            table is used, MySQL checks that the row length for all
             mapped tables is equal, but this is not foolproof. If you
             create a <literal>MERGE</literal> table from dissimilar
             <literal>MyISAM</literal> tables, you are very likely to run
@@ -2244,7 +2239,7 @@
 
       <listitem>
         <para>
-          <literal>MEMORY</literal> tables use a fixed record length
+          <literal>MEMORY</literal> tables use a fixed row length
           format.
         </para>
       </listitem>
@@ -3405,9 +3400,9 @@
         <literal>users</literal>, the <literal>MyISAM</literal> handler
         creates a data file named <literal>users.MYD</literal>. A
         handler for local tables reads, inserts, deletes, and updates
-        data in local data files, and records are stored in a format
-        particular to the handler. To read records, the handler must
-        parse data into columns. To write records, column values must be
+        data in local data files, and rows are stored in a format
+        particular to the handler. To read rows, the handler must parse
+        data into columns. To write rows, column values must be
         converted to the row format used by the handler and written to
         the local data file.
       </para>
@@ -3799,8 +3794,8 @@
     </para>
 
     <para>
-      <emphasis role="bold">Storage:</emphasis> Records are compressed
-      as they are inserted. The <literal>ARCHIVE</literal> engine uses
+      <emphasis role="bold">Storage:</emphasis> Rows are compressed as
+      they are inserted. The <literal>ARCHIVE</literal> engine uses
       <ulink url="http://www.zlib.net/">zlib</ulink> lossless data
       compression. Use of <literal>OPTIMIZE TABLE</literal> can analyze
       the table and pack it into a smaller format (for a reason to use
@@ -3837,8 +3832,8 @@
     </itemizedlist>
 
     <para>
-      <emphasis role="bold">Retrieval</emphasis>: On retrieval, records
-      are uncompressed on demand; there is no row cache. A
+      <emphasis role="bold">Retrieval</emphasis>: On retrieval, rows are
+      uncompressed on demand; there is no row cache. A
       <literal>SELECT</literal> operation performs a complete table
       scan: When a <literal>SELECT</literal> occurs, it finds out how
       many rows are currently available and reads that number of rows.

Modified: trunk/refman-5.1/database-administration.xml
===================================================================
--- trunk/refman-5.1/database-administration.xml	2006-01-12 18:19:12 UTC (rev 779)
+++ trunk/refman-5.1/database-administration.xml	2006-01-12 19:15:52 UTC (rev 780)
@@ -23597,8 +23597,9 @@
         In MySQL &current-series;'s slow query log, slow queries that do
         not use indexes are logged as well as those that do. To prevent
         queries that do not use indexes from being logged in the slow
-        query log, use the <option>--log-queries-not-using-indexes</option> option.
-        See <xref linkend="server-options"/>.
+        query log, use the
+        <option>--log-queries-not-using-indexes</option> option. See
+        <xref linkend="server-options"/>.
       </para>
 
       <para>

Modified: trunk/refman-5.1/functions.xml
===================================================================
--- trunk/refman-5.1/functions.xml	2006-01-12 18:19:12 UTC (rev 779)
+++ trunk/refman-5.1/functions.xml	2006-01-12 19:15:52 UTC (rev 780)
@@ -14039,9 +14039,9 @@
           <para>
             You can set a maximum allowed length with the
             <literal>group_concat_max_len</literal> system variable.
-            (The default value is 1024.)
-            The syntax to do this at runtime is as follows, where
-            <replaceable>val</replaceable> is an unsigned integer:
+            (The default value is 1024.) The syntax to do this at
+            runtime is as follows, where <replaceable>val</replaceable>
+            is an unsigned integer:
           </para>
 
 <programlisting>

Modified: trunk/refman-5.1/innodb.xml
===================================================================
--- trunk/refman-5.1/innodb.xml	2006-01-12 18:19:12 UTC (rev 779)
+++ trunk/refman-5.1/innodb.xml	2006-01-12 19:15:52 UTC (rev 780)
@@ -1896,8 +1896,7 @@
 
     <para>
       To create an <literal>InnoDB</literal> table, you must specify an
-      <literal>ENGINE = InnoDB</literal> option
-in the <literal>CREATE
+      <literal>ENGINE = InnoDB</literal> option in the <literal>CREATE
       TABLE</literal> statement:
     </para>
 
@@ -2794,7 +2793,7 @@
         writes SQL statements that modify data. A transaction that fails
         (for example, because of a foreign key violation, or because it
         is is rolled back) is not written to the binary log, so it is
-        not sent to slaves.
+        not sent to slaves. See <xref linkend="commit"/>.
       </para>
 
     </section>

Modified: trunk/refman-5.1/ndbcluster.xml
===================================================================
--- trunk/refman-5.1/ndbcluster.xml	2006-01-12 18:19:12 UTC (rev 779)
+++ trunk/refman-5.1/ndbcluster.xml	2006-01-12 19:15:52 UTC (rev 780)
@@ -4310,7 +4310,7 @@
             <para>
               Reads and updates set lock bits and update a header in the
               hash index entry. These changes are handled by the
-              page-writing algorithm to insure that these operations
+              page-writing algorithm to ensure that these operations
               need no UNDO logging.
             </para>
 
@@ -4888,7 +4888,7 @@
               <literal>1</literal>/<literal>0</literal>) parameter, and
               is disabled by default. When it is enabled, checksums for
               all messages are calculated before they placed in the send
-              buffer. This feature insures that messages are not
+              buffer. This feature ensures that messages are not
               corrupted while waiting in the send buffer, or by the
               transport mechanism.
             </para>
@@ -8388,7 +8388,7 @@
         The NDB <firstterm>binlog injector thread</firstterm> receives
         events directly from the NDB storage engine. The NDB injector is
         responsible for capturing all the data events within the cluster,
-        and insures that all events changing, inserting, or deleting data
+        and ensures that all events changing, inserting, or deleting data
         are recorded in the <literal>binlog_index</literal> table. The
         slave I/O thread will transfer the from the master's binary log to the slave's relay log.
       </para>

Modified: trunk/refman-5.1/partitioning.xml
===================================================================
--- trunk/refman-5.1/partitioning.xml	2006-01-12 18:19:12 UTC (rev 779)
+++ trunk/refman-5.1/partitioning.xml	2006-01-12 19:15:52 UTC (rev 780)
@@ -470,7 +470,7 @@
       <literal>1</literal>, <literal>2</literal>, and
       <literal>3</literal>. For the <literal>RANGE</literal> and
       <literal>LIST</literal> partitioning types, it is necessary to
-      insure that there is a partition defined for each partition
+      ensure that there is a partition defined for each partition
       number. For <literal>HASH</literal> partitioning, the user
       function employed must return an integer value greater than
       <literal>0</literal>. For <literal>KEY</literal> partitioning,

Modified: trunk/refman-5.1/storage-engines.xml
===================================================================
--- trunk/refman-5.1/storage-engines.xml	2006-01-12 18:19:12 UTC (rev 779)
+++ trunk/refman-5.1/storage-engines.xml	2006-01-12 19:15:52 UTC (rev 780)
@@ -175,7 +175,7 @@
 
       <para>
         <emphasis role="bold">Note</emphasis>: The
-        <literal>MEMORY</literal> storage engine was formerly known as
+        <literal>MEMORY</literal> storage engine formerly was known as
         the <literal>HEAP</literal> engine.
       </para>
     </listitem>
@@ -227,7 +227,7 @@
     <listitem>
       <para>
         The <literal>CSV</literal> storage engine stores data in text
-        files using comma-separated-values format.
+        files using comma-separated values format.
       </para>
     </listitem>
 
@@ -241,10 +241,10 @@
     <listitem>
       <para>
         The <literal>FEDERATED</literal> storage engine stores data in a
-        remote database. In MySQL &current-series;, it works with MySQL
-        only, using the MySQL C Client API. In future releases, we
-        intend to enable it to connect to other data sources using other
-        drivers or client connection methods.
+        remote database. Currently, it works with MySQL only, using the
+        MySQL C Client API. In future releases, we intend to enable it
+        to connect to other data sources using other drivers or client
+        connection methods.
       </para>
     </listitem>
 
@@ -262,8 +262,8 @@
   </para>
 
   <para>
-    When you create a new table, you can tell MySQL what type of table
-    to create by adding an <literal>ENGINE</literal> or
+    When you create a new table, you can specify which storage engine to
+    use by adding an <literal>ENGINE</literal> or
     <literal>TYPE</literal> table option to the <literal>CREATE
     TABLE</literal> statement:
   </para>
@@ -300,9 +300,9 @@
 
   <para>
     When MySQL is installed on Windows using the MySQL Configuration
-    Wizard, the <literal>InnoDB</literal> storage engine is the default
-    instead of <literal>MyISAM</literal>. See
-    <xref linkend="mysql-config-wizard-introduction"/>.
+    Wizard, the <literal>InnoDB</literal> storage engine can be selected
+    as the default instead of <literal>MyISAM</literal>. See
+    <xref linkend="mysql-config-wizard-database-usage"/>.
   </para>
 
   <para>
@@ -333,33 +333,34 @@
 
   <para>
     If you try to use a storage engine that is not compiled in or that
-    is compiled in but deactivated, MySQL instead creates a table of
-    type <literal>MyISAM</literal>. This behavior is convenient when you
-    want to copy tables between MySQL servers that support different
-    storage engines. (For example, in a replication setup, perhaps your
-    master server supports transactional storage engines for increased
-    safety, but the slave servers use only non-transactional storage
-    engines for greater speed.)
+    is compiled in but deactivated, MySQL instead creates a table using
+    the default storage engine, usually <literal>MyISAM</literal>. This
+    behavior is convenient when you want to copy tables between MySQL
+    servers that support different storage engines. (For example, in a
+    replication setup, perhaps your master server supports transactional
+    storage engines for increased safety, but the slave servers use only
+    non-transactional storage engines for greater speed.)
   </para>
 
   <para>
-    This automatic substitution of the <literal>MyISAM</literal> storage
-    engine when an unavailable engine is specified can be confusing for
-    new MySQL users. A warning is generated whenever a storage engine is
-    automatically changed.
+    This automatic substitution of the default storage engine for
+    unavailable engines can be confusing for new MySQL users. A warning
+    is generated whenever a storage engine is automatically changed.
   </para>
 
   <para>
-    MySQL always creates an <filename>.frm</filename> file to hold the
-    table and column definitions. The table's index and data may be
-    stored in one or more other files, depending on the storage engine.
-    The server creates the <filename>.frm</filename> file above the
-    storage engine level. Individual storage engines create any
-    additional files required for the tables that they manage.
+    For new tables, MySQL always creates an <filename>.frm</filename>
+    file to hold the table and column definitions. The table's index and
+    data may be stored in one or more other files, depending on the
+    storage engine. The server creates the <filename>.frm</filename>
+    file above the storage engine level. Individual storage engines
+    create any additional files required for the tables that they
+    manage.
   </para>
 
   <para>
-    A database may contain tables of different types.
+    A database may contain tables of different types. That is, tables
+    need not all be created with the same storage engine.
   </para>
 
   <para>
@@ -410,18 +411,18 @@
   </itemizedlist>
 
   <para>
-    Although MySQL supports several transaction-safe storage engines,
+    You can combine transaction-safe and non-transaction-safe tables in
+    the same statements to get the best of both worlds. However,
+    although MySQL supports several transaction-safe storage engines,
     for best results, you should not mix different storage engines
-    within a transaction. For information about the problems that can
-    occur if you do this, see <xref linkend="commit"/>.
+    within a transaction with autocommit disabled. For example, if you
+    do this, changes to non-transaction-safe tables still are committed
+    immediately and cannot be rolled back. For information about this
+    and other problems that can occur in transactions that use mixed
+    storage engines, see <xref linkend="commit"/>.
   </para>
 
   <para>
-    <literal>InnoDB</literal> uses default configuration values if you
-    specify none. See <xref linkend="innodb-configuration"/>.
-  </para>
-
-  <para>
     Non-transaction-safe tables have several advantages of their own,
     all of which occur because there is no transaction overhead:
   </para>
@@ -448,14 +449,6 @@
 
   </itemizedlist>
 
-  <para>
-    You can combine transaction-safe and non-transaction-safe tables in
-    the same statements to get the best of both worlds. However, within
-    a transaction with autocommit disabled, changes to
-    non-transaction-safe tables still are committed immediately and
-    cannot be rolled back.
-  </para>
-
   <section id="myisam-storage-engine">
 
     <title>&title-myisam-storage-engine;</title>
@@ -508,23 +501,27 @@
     </para>
 
     <para>
-      Normally, the <literal>ENGINE</literal> option is unnecessary;
-      <literal>MyISAM</literal> is the default storage engine unless the
-      default has been changed.
+      Normally, it is unnecesary to use <literal>ENGINE</literal> to
+      specify the <literal>MyISAM</literal> storage engine.
+      <literal>MyISAM</literal> is the default engine unless the default
+      has been changed. To ensure that <literal>MyISAM</literal> is used
+      in situations where the default might have been changed, include
+      the <literal>ENGINE</literal> option explicitly.
     </para>
 
     <para>
       You can check or repair <literal>MyISAM</literal> tables with the
-      <command>myisamchk</command> utility. See
-      <xref linkend="crash-recovery"/>. You can also compress
+      <command>mysqlcheck</command> client or
+      <command>myisamchk</command> utility. You can also compress
       <literal>MyISAM</literal> tables with
       <command>myisampack</command> to take up much less space. See
-      <xref linkend="myisampack"/>.
+      <xref linkend="mysqlcheck"/>, <xref linkend="crash-recovery"/>,
+      and <xref linkend="myisampack"/>.
     </para>
 
     <para>
-      The following are some characteristics of the
-      <literal>MyISAM</literal> storage engine:
+      <literal>MyISAM</literal> tables have the following
+      characteristics:
     </para>
 
     <itemizedlist>
@@ -533,11 +530,10 @@
         <para>
           All data values are stored with the low byte first. This makes
           the data machine and operating system independent. The only
-          requirement for binary portability is that the machine uses
-          two's-complement signed integers (as every machine for the
-          last 20 years has) and IEEE floating-point format (also
-          totally dominant among mainstream machines). The only area of
-          machines that may not support binary compatibility are
+          requirements for binary portability are that the machine uses
+          two's-complement signed integers and IEEE floating-point
+          format. These requirements are widely used among mainstream
+          machines. Binary compatibility might not be applicable to
           embedded systems, which sometimes have peculiar processors.
         </para>
 
@@ -614,10 +610,10 @@
 
       <listitem>
         <para>
-          When records are inserted in sorted order (as when you are
-          using an <literal>AUTO_INCREMENT</literal> column), the index
-          tree is split so that the high node only contains one key.
-          This improves space utilization in the index tree.
+          When rows are inserted in sorted order (as when you are using
+          an <literal>AUTO_INCREMENT</literal> column), the index tree
+          is split so that the high node only contains one key. This
+          improves space utilization in the index tree.
         </para>
       </listitem>
 
@@ -722,7 +718,7 @@
       <listitem>
         <para>
           Tables with <literal>VARCHAR</literal> may have fixed or
-          dynamic record length.
+          dynamic row length.
         </para>
       </listitem>
 
@@ -1039,7 +1035,7 @@
           can be found on disk: When looking up a row based on a row
           number in the index, multiply the row number by the row
           length. Also, when scanning a table, it is very easy to read a
-          constant number of records with each disk read operation.
+          constant number of rows with each disk read operation.
         </para>
 
         <para>
@@ -1047,14 +1043,14 @@
           MySQL server is writing to a fixed-format
           <literal>MyISAM</literal> file. In this case,
           <command>myisamchk</command> can easily determine where each
-          row starts and ends, so it can usually reclaim all records
-          except the partially written one. Note that
-          <literal>MyISAM</literal> table indexes can always be
-          reconstructed based on the data rows.
+          row starts and ends, so it can usually reclaim all rows except
+          the partially written one. Note that <literal>MyISAM</literal>
+          table indexes can always be reconstructed based on the data
+          rows.
         </para>
 
         <para>
-          General characteristics of static format tables:
+          Static-format tables have these characteristics:
         </para>
 
         <itemizedlist>
@@ -1080,7 +1076,7 @@
 
           <listitem>
             <para>
-              Easy to reconstruct after a crash, because records are
+              Easy to reconstruct after a crash, because rows are
               located in fixed positions.
             </para>
           </listitem>
@@ -1088,8 +1084,8 @@
           <listitem>
             <para>
               Reorganization is unnecessary unless you delete a huge
-              number of records and want to return free disk space to
-              the operating system. To do this, use <literal>OPTIMIZE
+              number of rows and want to return free disk space to the
+              operating system. To do this, use <literal>OPTIMIZE
               TABLE</literal> or <command>myisamchk -r</command>.
             </para>
           </listitem>
@@ -1128,9 +1124,9 @@
 
         <para>
           This format is a little more complex because each row has a
-          header that indicates how long it is. One record can also end
-          up at more than one location when it is made longer as a
-          result of an update.
+          header that indicates how long it is. One row can also end up
+          at more than one location when it is made longer as a result
+          of an update.
         </para>
 
         <indexterm>
@@ -1148,7 +1144,7 @@
         </para>
 
         <para>
-          General characteristics of dynamic-format tables:
+          Dynamic-format tables have these characteristics:
         </para>
 
         <itemizedlist>
@@ -1162,7 +1158,7 @@
 
           <listitem>
             <para>
-              Each record is preceded by a bitmap that indicates which
+              Each row is preceded by a bitmap that indicates which
               columns contain the empty string (for string columns) or
               zero (for numeric columns). Note that this does not
               include columns that contain <literal>NULL</literal>
@@ -1183,30 +1179,29 @@
 
           <listitem>
             <para>
-              Each record uses only as much space as is required.
-              However, if a record becomes larger, it is split into as
-              many pieces as are required, resulting in record
-              fragmentation. For example, if you update a row with
-              information that extends the row length, the row becomes
-              fragmented. In this case, you may have to run
-              <literal>OPTIMIZE TABLE</literal> or <command>myisamchk
-              -r</command> from time to time to improve performance. Use
-              <command>myisamchk -ei</command> to obtain table
-              statistics.
+              Each row uses only as much space as is required. However,
+              if a row becomes larger, it is split into as many pieces
+              as are required, resulting in row fragmentation. For
+              example, if you update a row with information that extends
+              the row length, the row becomes fragmented. In this case,
+              you may have to run <literal>OPTIMIZE TABLE</literal> or
+              <command>myisamchk -r</command> from time to time to
+              improve performance. Use <command>myisamchk -ei</command>
+              to obtain table statistics.
             </para>
           </listitem>
 
           <listitem>
             <para>
               More difficult than static-format tables to reconstruct
-              after a crash, because a record may be fragmented into
-              many pieces and a link (fragment) may be missing.
+              after a crash, because a row may be fragmented into many
+              pieces and a link (fragment) may be missing.
             </para>
           </listitem>
 
           <listitem>
             <para>
-              The expected row length for dynamic-sized records is
+              The expected row length for dynamic-sized rows is
               calculated using the following expression:
             </para>
 
@@ -1220,10 +1215,10 @@
 </programlisting>
 
             <para>
-              There is a penalty of 6 bytes for each link. A dynamic
-              record is linked whenever an update causes an enlargement
-              of the record. Each new link is at least 20 bytes, so the
-              next enlargement probably goes in the same link. If not,
+              There is a penalty of 6 bytes for each link. A dynamic row
+              is linked whenever an update causes an enlargement of the
+              row. Each new link is at least 20 bytes, so the next
+              enlargement probably goes in the same link. If not,
               another link is created. You can find the number of links
               using <command>myisamchk -ed</command>. All links may be
               removed with <command>myisamchk -r</command>.
@@ -1283,10 +1278,10 @@
 
           <listitem>
             <para>
-              Each record is compressed separately, so there is very
-              little access overhead. The header for a record takes up 1
-              to 3 bytes depending on the biggest record in the table.
-              Each column is compressed differently. There is usually a
+              Each row is compressed separately, so there is very little
+              access overhead. The header for a row takes up 1 to 3
+              bytes depending on the biggest row in the table. Each
+              column is compressed differently. There is usually a
               different Huffman tree for each column. Some of the
               compression types are:
             </para>
@@ -1342,7 +1337,7 @@
 
           <listitem>
             <para>
-              Can handle fixed-length or dynamic-length records.
+              Can handle fixed-length or dynamic-length rows.
             </para>
           </listitem>
 
@@ -1687,8 +1682,8 @@
       <literal>LAST</literal> to cause inserts to be made in the first
       or last table, respectively. If you do not specify an
       <literal>INSERT_METHOD</literal> option or if you specify it with
-      a value of <literal>NO</literal>, attempts to insert records into
-      the <literal>MERGE</literal> table result in an error.
+      a value of <literal>NO</literal>, attempts to insert rows into the
+      <literal>MERGE</literal> table result in an error.
     </para>
 
     <para>
@@ -2008,9 +2003,9 @@
         <listitem>
           <para>
             When you create a <literal>MERGE</literal> table, there is
-            no check to insure that the underlying tables exist and have
+            no check to ensure that the underlying tables exist and have
             identical structures. When the <literal>MERGE</literal>
-            table is used, MySQL checks that the record length for all
+            table is used, MySQL checks that the row length for all
             mapped tables is equal, but this is not foolproof. If you
             create a <literal>MERGE</literal> table from dissimilar
             <literal>MyISAM</literal> tables, you are very likely to run
@@ -2244,7 +2239,7 @@
 
       <listitem>
         <para>
-          <literal>MEMORY</literal> tables use a fixed record length
+          <literal>MEMORY</literal> tables use a fixed row length
           format.
         </para>
       </listitem>
@@ -3430,9 +3425,9 @@
         <literal>users</literal>, the <literal>MyISAM</literal> handler
         creates a data file named <literal>users.MYD</literal>. A
         handler for local tables reads, inserts, deletes, and updates
-        data in local data files, and records are stored in a format
-        particular to the handler. To read records, the handler must
-        parse data into columns. To write records, column values must be
+        data in local data files, and rows are stored in a format
+        particular to the handler. To read rows, the handler must parse
+        data into columns. To write rows, column values must be
         converted to the row format used by the handler and written to
         the local data file.
       </para>
@@ -3839,8 +3834,8 @@
     </para>
 
     <para>
-      <emphasis role="bold">Storage:</emphasis> Records are compressed
-      as they are inserted. The <literal>ARCHIVE</literal> engine uses
+      <emphasis role="bold">Storage:</emphasis> Rows are compressed as
+      they are inserted. The <literal>ARCHIVE</literal> engine uses
       <ulink url="http://www.zlib.net/">zlib</ulink> lossless data
       compression. Use of <literal>OPTIMIZE TABLE</literal> can analyze
       the table and pack it into a smaller format (for a reason to use
@@ -3876,8 +3871,8 @@
     </itemizedlist>
 
     <para>
-      <emphasis role="bold">Retrieval</emphasis>: On retrieval, records
-      are uncompressed on demand; there is no row cache. A
+      <emphasis role="bold">Retrieval</emphasis>: On retrieval, rows are
+      uncompressed on demand; there is no row cache. A
       <literal>SELECT</literal> operation performs a complete table
       scan: When a <literal>SELECT</literal> occurs, it finds out how
       many rows are currently available and reads that number of rows.

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