List:Commits« Previous MessageNext Message »
From:paul Date:January 10 2006 5:56am
Subject:svn commit - mysqldoc@docsrva: r751 - in trunk: . refman-4.1 refman-5.0 refman-5.1 refman-common
View as plain text  
Author: paul
Date: 2006-01-10 06:55:56 +0100 (Tue, 10 Jan 2006)
New Revision: 751

Log:
 r6026@frost:  paul | 2006-01-09 23:52:23 -0600
 General revisions.


Modified:
   trunk/
   trunk/refman-4.1/apis.xml
   trunk/refman-4.1/charset.xml
   trunk/refman-4.1/client-utility-programs.xml
   trunk/refman-4.1/extending-mysql.xml
   trunk/refman-4.1/functions.xml
   trunk/refman-4.1/innodb.xml
   trunk/refman-4.1/installing.xml
   trunk/refman-4.1/ndbcluster.xml
   trunk/refman-4.1/optimization.xml
   trunk/refman-4.1/problems.xml
   trunk/refman-4.1/sql-syntax.xml
   trunk/refman-4.1/storage-engines.xml
   trunk/refman-4.1/tutorial.xml
   trunk/refman-5.0/apis.xml
   trunk/refman-5.0/charset.xml
   trunk/refman-5.0/client-utility-programs.xml
   trunk/refman-5.0/extending-mysql.xml
   trunk/refman-5.0/functions.xml
   trunk/refman-5.0/innodb.xml
   trunk/refman-5.0/installing.xml
   trunk/refman-5.0/ndbcluster.xml
   trunk/refman-5.0/optimization.xml
   trunk/refman-5.0/problems.xml
   trunk/refman-5.0/sql-syntax.xml
   trunk/refman-5.0/storage-engines.xml
   trunk/refman-5.0/tutorial.xml
   trunk/refman-5.1/apis.xml
   trunk/refman-5.1/charset.xml
   trunk/refman-5.1/client-utility-programs.xml
   trunk/refman-5.1/custom-engine.xml
   trunk/refman-5.1/extending-mysql.xml
   trunk/refman-5.1/functions.xml
   trunk/refman-5.1/innodb.xml
   trunk/refman-5.1/ndbcluster.xml
   trunk/refman-5.1/optimization.xml
   trunk/refman-5.1/problems.xml
   trunk/refman-5.1/sql-syntax.xml
   trunk/refman-5.1/storage-engines.xml
   trunk/refman-5.1/tutorial.xml
   trunk/refman-common/news-3.22.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-connector-j.xml
   trunk/refman-common/news-connector-net.xml
   trunk/refman-common/news-innodb.xml
   trunk/refman-common/what-is.en.xml


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

Modified: trunk/refman-4.1/apis.xml
===================================================================
--- trunk/refman-4.1/apis.xml	2006-01-10 04:12:27 UTC (rev 750)
+++ trunk/refman-4.1/apis.xml	2006-01-10 05:55:56 UTC (rev 751)
@@ -8096,7 +8096,7 @@
                 For input, this is a pointer to the buffer in which a
                 statement parameter's data value is stored. For output,
                 it is a pointer to the buffer in which to return a
-                result set column value. For numeric column types,
+                result set column value. For numeric data types,
                 <literal>buffer</literal> should point to a variable of
                 the proper C type. (If you are associating the variable
                 with a column that has the <literal>UNSIGNED</literal>
@@ -8104,12 +8104,11 @@
                 <literal>unsigned</literal> C type. Indicate whether the
                 variable is signed or unsigned by using the
                 <literal>is_unsigned</literal> member, described later
-                in this list.) For date and time column types,
+                in this list.) For date and time data types,
                 <literal>buffer</literal> should point to a
                 <literal>MYSQL_TIME</literal> structure. For character
-                and binary string column types,
-                <literal>buffer</literal> should point to a character
-                buffer.
+                and binary string data types, <literal>buffer</literal>
+                should point to a character buffer.
               </para>
             </listitem>
 

Modified: trunk/refman-4.1/charset.xml
===================================================================
--- trunk/refman-4.1/charset.xml	2006-01-10 04:12:27 UTC (rev 750)
+++ trunk/refman-4.1/charset.xml	2006-01-10 05:55:56 UTC (rev 751)
@@ -2311,7 +2311,7 @@
       way to indicate that a <literal>CHAR</literal> column should use
       some predefined character set. MySQL 4.1 and up uses
       <literal>utf8</literal> as that predefined character set. For
-      example, these column type declarations are equivalent:
+      example, these data type declarations are equivalent:
     </para>
 
 <programlisting>
@@ -2646,7 +2646,7 @@
         should avoid trying to convert directly from
         <literal>latin1</literal> to the "real" character set. This may
         result in data loss. Instead, convert the column to a binary
-        column type, and then from the binary type to a non-binary type
+        data type, and then from the binary type to a non-binary type
         with the desired character set. Conversion to and from binary
         involves no attempt at character value conversion and preserves
         your data intact. For example, suppose that you have a 4.0 table

Modified: trunk/refman-4.1/client-utility-programs.xml
===================================================================
--- trunk/refman-4.1/client-utility-programs.xml	2006-01-10 04:12:27 UTC (rev 750)
+++ trunk/refman-4.1/client-utility-programs.xml	2006-01-10 05:55:56 UTC (rev 751)
@@ -989,8 +989,8 @@
             </para>
 
             <para>
-              The column type. The value may contain any of the
-              following descriptors:
+              The data type. The value may contain any of the following
+              descriptors:
             </para>
 
             <itemizedlist>

Modified: trunk/refman-4.1/extending-mysql.xml
===================================================================
--- trunk/refman-4.1/extending-mysql.xml	2006-01-10 04:12:27 UTC (rev 750)
+++ trunk/refman-4.1/extending-mysql.xml	2006-01-10 05:55:56 UTC (rev 751)
@@ -1266,7 +1266,7 @@
               If you want to return a blob value, you can set
               <literal>max_length</literal> to 65KB or 16MB. This memory
               is not allocated, but the value is used to decide which
-              column type to use if there is a need to temporarily store
+              data type to use if there is a need to temporarily store
               the data.
             </para>
           </listitem>
@@ -2350,8 +2350,8 @@
             <replaceable>max_elements</replaceable> (default 256) is the
             maximum number of distinct values <literal>analyse</literal>
             does notice per column. This is used by
-            <literal>analyse</literal> to check whether the optimal
-            column type should be of type <literal>ENUM</literal>.
+            <literal>analyse</literal> to check whether the optimal data
+            type should be of type <literal>ENUM</literal>.
           </para>
         </listitem>
 

Modified: trunk/refman-4.1/functions.xml
===================================================================
--- trunk/refman-4.1/functions.xml	2006-01-10 04:12:27 UTC (rev 750)
+++ trunk/refman-4.1/functions.xml	2006-01-10 05:55:56 UTC (rev 751)
@@ -11269,7 +11269,7 @@
       the <option>--sql-mode=NO_UNSIGNED_SUBTRACTION</option> option
       when starting <command>mysqld</command>. However, as long as you
       use this option, you are not able to make efficient use of the
-      <literal>BIGINT UNSIGNED</literal> column type.
+      <literal>BIGINT UNSIGNED</literal> data type.
     </para>
 
   </section>
@@ -11736,7 +11736,7 @@
           <para>
             The result is a binary string of the same length as
             <replaceable>str</replaceable>. If you want to save it in a
-            column, use a <literal>BLOB</literal> column type.
+            column, use a <literal>BLOB</literal> data type.
           </para>
 
           <remark role="help-description-end"/>

Modified: trunk/refman-4.1/innodb.xml
===================================================================
--- trunk/refman-4.1/innodb.xml	2006-01-10 04:12:27 UTC (rev 750)
+++ trunk/refman-4.1/innodb.xml	2006-01-10 05:55:56 UTC (rev 751)
@@ -2299,14 +2299,13 @@
 
         <listitem>
           <para>
-            <literal>NO ACTION</literal>: In the ANSI SQL-92 standard,
-            <literal>NO ACTION</literal> means <emphasis>no
-            action</emphasis> in the sense that an attempt to delete or
-            update a primary key value will not be allowed to proceed if
-            there is a related foreign key value in the referenced table
-            (Gruber, <citetitle>Mastering SQL</citetitle>, 2000:181).
-            Starting from 4.0.18 <literal>InnoDB</literal> rejects the
-            delete or update operation for the parent table.
+            <literal>NO ACTION</literal>: In standard sQL, <literal>NO
+            ACTION</literal> means <emphasis>no action</emphasis> in the
+            sense that an attempt to delete or update a primary key
+            value will not be allowed to proceed if there is a related
+            foreign key value in the referenced table. Starting from
+            4.0.18 <literal>InnoDB</literal> rejects the delete or
+            update operation for the parent table.
           </para>
         </listitem>
 
@@ -3086,7 +3085,9 @@
       If your database gets corrupted or your disk fails, you have to do
       the recovery from a backup. In the case of corruption, you should
       first find a backup that is not corrupted. After restoring the
-      base backup, do the recovery from the binary log files.
+      base backup, do the recovery from the binary log files using
+      <command>mysqlbinlog</command> and <command>mysql</command> to
+      restore the changes performed after the backup was made.
     </para>
 
     <para>
@@ -3104,8 +3105,8 @@
       In some cases, apparent database page corruption is actually due
       to the operating system corrupting its own file cache, and the
       data on disk may be okay. It is best first to try restarting your
-      computer. It may eliminate errors that appeared to be database
-      page corruption.
+      computer. Doing so may eliminate errors that appeared to be
+      database page corruption.
     </para>
 
     <section id="forcing-recovery">
@@ -3115,10 +3116,10 @@
       <para>
         If there is database page corruption, you may want to dump your
         tables from the database with <literal>SELECT INTO
-        OUTFILE</literal>; usually, most of the data obtained in this
+        OUTFILE</literal>. Usually, most of the data obtained in this
         way is intact. Even so, the corruption may cause <literal>SELECT
-        * FROM <replaceable>tbl_name</replaceable></literal> or
-        <literal>InnoDB</literal> background operations to crash or
+        * FROM <replaceable>tbl_name</replaceable></literal> statements
+        or <literal>InnoDB</literal> background operations to crash or
         assert, or even the <literal>InnoDB</literal> roll-forward
         recovery to crash. Starting from MySQL 3.23.44, there is an
         <literal>InnoDB</literal> variable that you can use to force the
@@ -3146,11 +3147,11 @@
       <para>
         The allowable non-zero values for
         <literal>innodb_force_recovery</literal> follow. A larger number
-        includes all precautions of lower numbers. If you are able to
+        includes all precautions of smaller numbers. If you are able to
         dump your tables with an option value of at most 4, then you are
         relatively safe that only some data on corrupt individual pages
-        is lost. A value of 6 is more dramatic, because database pages
-        are left in an obsolete state, which in turn may introduce more
+        is lost. A value of 6 is more drastic because database pages are
+        left in an obsolete state, which in turn may introduce more
         corruption into B-trees and other database structures.
       </para>
 
@@ -3163,7 +3164,7 @@
           </para>
 
           <para>
-            Let the server run even if it detects a corrupt page; try to
+            Let the server run even if it detects a corrupt page. Try to
             make <literal>SELECT * FROM
             <replaceable>tbl_name</replaceable></literal> jump over
             corrupt index records and pages, which helps in dumping
@@ -3179,7 +3180,7 @@
 
           <para>
             Prevent the main thread from running. If a crash would occur
-            during the purge operation, this prevents it.
+            during the purge operation, this recovery value prevents it.
           </para>
         </listitem>
 
@@ -3202,7 +3203,7 @@
 
           <para>
             Prevent also insert buffer merge operations. If they would
-            cause a crash, better not do them; do not calculate table
+            cause a crash, do not do them. Do not calculate table
             statistics.
           </para>
         </listitem>
@@ -3234,17 +3235,8 @@
       </itemizedlist>
 
       <para>
-        <emphasis>The database must not otherwise be used with any of
-        these options enabled</emphasis>. As a safety measure,
-        <literal>InnoDB</literal> prevents users from performing
-        <literal>INSERT</literal>, <literal>UPDATE</literal>, or
-        <literal>DELETE</literal> operations when
-        <literal>innodb_force_recovery</literal> is set to a value
-        greater than 0.
-      </para>
-
-      <para>
-        Starting from MySQL 3.23.53 and 4.0.4, you are allowed to
+        Starting from MySQL 3.23.53 and 4.0.4, you can
+        <literal>SELECT</literal> from tables to dump them, or
         <literal>DROP</literal> or <literal>CREATE</literal> a table
         even if forced recovery is used. If you know that a certain
         table is causing a crash in rollback, you can drop it. You can
@@ -3257,6 +3249,16 @@
         rollback.
       </para>
 
+      <para>
+        <emphasis>The database must not otherwise be used with any
+        non-zero value of
+        <literal>innodb_force_recovery</literal></emphasis>. As a safety
+        measure, <literal>InnoDB</literal> prevents users from
+        performing <literal>INSERT</literal>, <literal>UPDATE</literal>,
+        or <literal>DELETE</literal> operations when
+        <literal>innodb_force_recovery</literal> is greater than 0.
+      </para>
+
     </section>
 
     <section id="innodb-checkpoints">
@@ -3283,26 +3285,26 @@
       </para>
 
       <para>
-        <literal>InnoDB</literal> writes to the log files on a rotating
+        <literal>InnoDB</literal> writes to its log files on a rotating
         basis. All committed modifications that make the database pages
         in the buffer pool different from the images on disk must be
         available in the log files in case <literal>InnoDB</literal> has
         to do a recovery. This means that when <literal>InnoDB</literal>
         starts to reuse a log file, it has to make sure that the
         database page images on disk contain the modifications logged in
-        the log file <literal>InnoDB</literal> is going to reuse. In
-        other words, <literal>InnoDB</literal> must create a checkpoint
-        and this often involves flushing of modified database pages to
-        disk.
+        the log file that <literal>InnoDB</literal> is going to reuse.
+        In other words, <literal>InnoDB</literal> must create a
+        checkpoint and this often involves flushing of modified database
+        pages to disk.
       </para>
 
       <para>
         The preceding description explains why making your log files
         very large may save disk I/O in checkpointing. It often makes
         sense to set the total size of the log files as big as the
-        buffer pool or even bigger. The drawback of big log files is
-        that crash recovery can take longer because there is more logged
-        information to apply to the database.
+        buffer pool or even bigger. The drawback of using large log
+        files is that crash recovery can take longer because there is
+        more logged information to apply to the database.
       </para>
 
     </section>
@@ -3320,8 +3322,8 @@
       have all table and database names in lowercase. A convenient way
       to accomplish this is to add the following line to the
       <literal>[mysqld]</literal> section of your
-      <filename>my.cnf</filename> or <filename>my.ini</filename> before
-      creating any databases or tables:
+      <filename>my.cnf</filename> or <filename>my.ini</filename> file
+      before creating any databases or tables:
     </para>
 
 <programlisting>
@@ -3359,9 +3361,9 @@
     <title>&title-innodb-transaction-model;</title>
 
     <para>
-      In the <literal>InnoDB</literal> transaction model, the goal has
-      been to combine the best properties of a multi-versioning database
-      with traditional two-phase locking. <literal>InnoDB</literal> does
+      In the <literal>InnoDB</literal> transaction model, the goal is to
+      combine the best properties of a multi-versioning database with
+      traditional two-phase locking. <literal>InnoDB</literal> does
       locking on the row level and runs queries as non-locking
       consistent reads by default, in the style of Oracle. The lock
       table in <literal>InnoDB</literal> is stored so space-efficiently
@@ -3398,20 +3400,9 @@
       </itemizedlist>
 
       <para>
-        If a transaction <replaceable>A</replaceable> holds an exclusive
-        (<replaceable>X</replaceable>) lock on tuple
-        <replaceable>t</replaceable>, then a request from some distinct
-        transaction <replaceable>B</replaceable> for a lock of either
-        type on <replaceable>t</replaceable> cannot be granted
-        immediately. Instead, transaction <replaceable>B</replaceable>
-        has to wait for transaction <replaceable>A</replaceable> to
-        release its lock on tuple <replaceable>t</replaceable>.
-      </para>
-
-      <para>
-        If transaction <replaceable>A</replaceable> holds a shared
+        If transaction <literal>T1</literal> holds a shared
         (<replaceable>S</replaceable>) lock on tuple
-        <replaceable>t</replaceable>, then
+        <literal>t</literal>, then
       </para>
 
       <itemizedlist>
@@ -3419,41 +3410,49 @@
         <listitem>
           <para>
             A request from some distinct transaction
-            <replaceable>B</replaceable> for an
-            <replaceable>X</replaceable> lock on
-            <replaceable>t</replaceable> cannot be granted immediately.
+            <literal>T2</literal> for an <replaceable>S</replaceable>
+            lock on <literal>t</literal> can be granted immediately. As
+            a result, both <literal>T1</literal> and
+            <literal>T2</literal> hold an <replaceable>S</replaceable>
+            lock on <literal>t</literal>.
           </para>
         </listitem>
 
         <listitem>
           <para>
             A request from some distinct transaction
-            <replaceable>B</replaceable> for an
-            <replaceable>S</replaceable> lock on
-            <replaceable>t</replaceable> can be granted immediately. As
-            a result, both <replaceable>A</replaceable> and
-            <replaceable>B</replaceable> hold an
-            <replaceable>S</replaceable> lock on
-            <replaceable>t</replaceable>.
+            <literal>T2</literal> for an <replaceable>X</replaceable>
+            lock on <literal>t</literal> cannot be granted immediately.
           </para>
         </listitem>
 
       </itemizedlist>
 
       <para>
+        If a transaction <literal>T1</literal> holds an exclusive
+        (<replaceable>X</replaceable>) lock on tuple
+        <literal>t</literal>, then a request from some distinct
+        transaction <literal>T2</literal> for a lock of either type on
+        <literal>t</literal> cannot be granted immediately. Instead,
+        transaction <literal>T2</literal> has to wait for transaction
+        <literal>T1</literal> to release its lock on tuple
+        <literal>t</literal>.
+      </para>
+
+      <para>
         Additionally, <literal>InnoDB</literal> supports
         <emphasis>multiple granularity locking</emphasis> which allows
         coexistence of record locks and locks on entire tables. To make
         locking at multiple granularity levels practical, additional
-        types of locks, called <emphasis>intention locks</emphasis> are
+        types of locks called <emphasis>intention locks</emphasis> are
         used. Intention locks are table locks in
         <literal>InnoDB</literal>. The idea behind intention locks is
         for a transaction to indicate which type of lock (shared or
         exclusive) it will require later for a row in that table. There
         are two types of intention locks used in
         <literal>InnoDB</literal> (assume that transaction
-        <replaceable>T</replaceable> has requested a lock of the
-        indicated type on table <replaceable>R</replaceable>):
+        <literal>T</literal> has requested a lock of the indicated type
+        on table <literal>R</literal>):
       </para>
 
       <itemizedlist>
@@ -3461,17 +3460,17 @@
         <listitem>
           <para>
             Intention shared (<replaceable>IS</replaceable>):
-            Transaction <replaceable>T</replaceable> intends to set
-            <replaceable>S</replaceable> locks on individual tuples in
-            table <replaceable>T</replaceable>.
+            Transaction <literal>T</literal> intends to set
+            <replaceable>S</replaceable> locks on individual rows in
+            table <literal>R</literal>.
           </para>
         </listitem>
 
         <listitem>
           <para>
             Intention exclusive (<replaceable>IX</replaceable>):
-            Transaction <replaceable>T</replaceable> intends to set
-            <replaceable>X</replaceable> locks on those tuples.
+            Transaction <literal>T</literal> intends to set
+            <replaceable>X</replaceable> locks on those rows.
           </para>
         </listitem>
 
@@ -3511,41 +3510,41 @@
       <informaltable>
         <tgroup cols="5">
           <colspec colwidth="20*"/>
-          <colspec colwidth="10*"/>
-          <colspec colwidth="10*"/>
-          <colspec colwidth="10*"/>
-          <colspec colwidth="10*"/>
+          <colspec colwidth="20*"/>
+          <colspec colwidth="20*"/>
+          <colspec colwidth="20*"/>
+          <colspec colwidth="20*"/>
           <tbody>
             <row>
               <entry/>
-              <entry>X</entry>
-              <entry>IX</entry>
-              <entry>S</entry>
-              <entry>IS</entry>
+              <entry><replaceable>X</replaceable></entry>
+              <entry><replaceable>IX</replaceable></entry>
+              <entry><replaceable>S</replaceable></entry>
+              <entry><replaceable>IS</replaceable></entry>
             </row>
             <row>
-              <entry>X</entry>
+              <entry><replaceable>X</replaceable></entry>
               <entry>Conflict</entry>
               <entry>Conflict</entry>
               <entry>Conflict</entry>
               <entry>Conflict</entry>
             </row>
             <row>
-              <entry>IX</entry>
+              <entry><replaceable>IX</replaceable></entry>
               <entry>Conflict</entry>
               <entry>Compatible</entry>
               <entry>Conflict</entry>
               <entry>Compatible</entry>
             </row>
             <row>
-              <entry>S</entry>
+              <entry><replaceable>S</replaceable></entry>
               <entry>Conflict</entry>
               <entry>Conflict</entry>
               <entry>Compatible</entry>
               <entry>Compatible</entry>
             </row>
             <row>
-              <entry>IS</entry>
+              <entry><replaceable>IS</replaceable></entry>
               <entry>Conflict</entry>
               <entry>Compatible</entry>
               <entry>Compatible</entry>
@@ -4714,7 +4713,7 @@
 
       <listitem>
         <para>
-          Use the <literal>VARCHAR</literal> column type instead of
+          Use the <literal>VARCHAR</literal> data type instead of
           <literal>CHAR</literal> if you are storing variable-length
           strings or if the column may contain many
           <literal>NULL</literal> values. A

Modified: trunk/refman-4.1/installing.xml
===================================================================
--- trunk/refman-4.1/installing.xml	2006-01-10 04:12:27 UTC (rev 750)
+++ trunk/refman-4.1/installing.xml	2006-01-10 05:55:56 UTC (rev 751)
@@ -12404,8 +12404,8 @@
             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:
+            strictly legal for the data type, you should alter the data
+            types of those columns. For example:
           </para>
 
 <programlisting>

Modified: trunk/refman-4.1/ndbcluster.xml
===================================================================
--- trunk/refman-4.1/ndbcluster.xml	2006-01-10 04:12:27 UTC (rev 750)
+++ trunk/refman-4.1/ndbcluster.xml	2006-01-10 05:55:56 UTC (rev 751)
@@ -10036,13 +10036,13 @@
 
       <listitem>
         <para>
-          <emphasis>What column types are supported by MySQL
+          <emphasis>What data types are supported by MySQL
           Cluster?</emphasis>
         </para>
 
         <para>
-          MySQL Cluster supports all of the usual MySQL column types,
-          with the exception of those associated with MySQL's spatial
+          MySQL Cluster supports all of the usual MySQL data types, with
+          the exception of those associated with MySQL's spatial
           extensions. (See <xref linkend="spatial-extensions"/>.) In
           addition, there are some differences with regard to indexes
           when used with <literal>NDB</literal> tables.
@@ -10662,7 +10662,7 @@
           <emphasis role="bold">D</emphasis>ata<emphasis role="bold">b</emphasis>ase,
           and refers to the storage engine used to enable MySQL Cluster.
           The <literal>NDB</literal> storage engine supports all the
-          usual MySQL column types and SQL statements, and is
+          usual MySQL data types and SQL statements, and is
           ACID-compliant. This engine also provides full support for
           transactions (commits and rollbacks).
         </para>

Modified: trunk/refman-4.1/optimization.xml
===================================================================
--- trunk/refman-4.1/optimization.xml	2006-01-10 04:12:27 UTC (rev 750)
+++ trunk/refman-4.1/optimization.xml	2006-01-10 05:55:56 UTC (rev 751)
@@ -497,7 +497,7 @@
 
         <listitem>
           <para>
-            What column types are supported
+            What data types are supported
           </para>
         </listitem>
 
@@ -1578,7 +1578,7 @@
                 <row>
                   <entry><emphasis role="bold">Table</emphasis></entry>
                   <entry><emphasis role="bold">Column</emphasis></entry>
-                  <entry><emphasis role="bold">Column Type</emphasis></entry>
+                  <entry><emphasis role="bold">Data Type</emphasis></entry>
                 </row>
                 <row>
                   <entry><literal>tt</literal></entry>
@@ -5286,7 +5286,7 @@
       </indexterm>
 
       <para>
-        All MySQL column types can be indexed. Use of indexes on the
+        All MySQL data types can be indexed. Use of indexes on the
         relevant columns is the best way to improve the performance of
         <literal>SELECT</literal> operations.
       </para>
@@ -5365,8 +5365,8 @@
       </para>
 
       <para>
-        As of MySQL 4.1.0, you can create indexes on spatial column
-        types. Currently, spatial types are supported only by the
+        As of MySQL 4.1.0, you can create indexes on spatial data types.
+        Currently, spatial types are supported only by the
         <literal>MyISAM</literal> storage engine. Spatial indexes use
         R-trees.
       </para>
@@ -5399,7 +5399,7 @@
 
       <para>
         MySQL can create indexes on multiple columns. An index may
-        consist of up to 15 columns. For certain column types, you can
+        consist of up to 15 columns. For certain data types, you can
         index a prefix of the column (see <xref linkend="indexes"/>).
       </para>
 
@@ -5502,7 +5502,7 @@
         Most MySQL indexes (<literal>PRIMARY KEY</literal>,
         <literal>UNIQUE</literal>, <literal>INDEX</literal>, and
         <literal>FULLTEXT</literal>) are stored in B-trees. Exceptions
-        are that indexes on spatial column types use R-trees, and that
+        are that indexes on spatial data types use R-trees, and that
         <literal>MEMORY</literal> (<literal>HEAP</literal>) tables
         support hash indexes.
       </para>

Modified: trunk/refman-4.1/problems.xml
===================================================================
--- trunk/refman-4.1/problems.xml	2006-01-10 04:12:27 UTC (rev 750)
+++ trunk/refman-4.1/problems.xml	2006-01-10 05:55:56 UTC (rev 751)
@@ -3712,7 +3712,7 @@
       </indexterm>
 
       <para>
-        For some column types, MySQL handles <literal>NULL</literal>
+        For some data types, MySQL handles <literal>NULL</literal>
         values specially. If you insert <literal>NULL</literal> into a
         <literal>TIMESTAMP</literal> column, the current date and time
         is inserted. If you insert <literal>NULL</literal> into an
@@ -4045,7 +4045,7 @@
         Floating-point numbers sometimes cause confusion because they
         are not stored as exact values inside computer architecture.
         What you can see on the screen usually is not the exact value of
-        the number. The column types <literal>FLOAT</literal>,
+        the number. The data types <literal>FLOAT</literal>,
         <literal>DOUBLE</literal>, and <literal>DECIMAL</literal> are
         such. <literal>DECIMAL</literal> columns store values with exact
         precision because they are represented as strings, but
@@ -4056,11 +4056,10 @@
       <para>
         The following example (for older MySQL version than 5.0.3)
         demonstrate the problem. It shows that even for the
-        <literal>DECIMAL</literal> column type, calculations that are
-        done using floating-point operations are subject to
-        floating-point error. (In all MySQL versions, you would have
-        similar problems if you would replace the
-        <literal>DECIMAL</literal> columns with
+        <literal>DECIMAL</literal> data type, calculations that are done
+        using floating-point operations are subject to floating-point
+        error. (In all MySQL versions, you would have similar problems
+        if you would replace the <literal>DECIMAL</literal> columns with
         <literal>FLOAT</literal>).
       </para>
 

Modified: trunk/refman-4.1/sql-syntax.xml
===================================================================
--- trunk/refman-4.1/sql-syntax.xml	2006-01-10 04:12:27 UTC (rev 750)
+++ trunk/refman-4.1/sql-syntax.xml	2006-01-10 05:55:56 UTC (rev 751)
@@ -305,7 +305,7 @@
             same syntax for <literal>ADD</literal> and
             <literal>CHANGE</literal> as for <literal>CREATE
             TABLE</literal>. Note that this syntax includes the column
-            name, not just the column type. See
+            name, not just its data type. See
             <xref linkend="create-table"/>.
           </para>
         </listitem>
@@ -359,10 +359,9 @@
 
         <listitem>
           <para>
-            When you change a column type using
-            <literal>CHANGE</literal> or <literal>MODIFY</literal>,
-            MySQL tries to convert existing column values to the new
-            type as well as possible.
+            When you change a data type using <literal>CHANGE</literal>
+            or <literal>MODIFY</literal>, MySQL tries to convert
+            existing column values to the new type as well as possible.
           </para>
         </listitem>
 
@@ -1182,7 +1181,7 @@
         <literal>SPATIAL</literal> indexes can include only spatial
         columns, and only in <literal>MyISAM</literal> tables.
         <literal>SPATIAL</literal> indexes are available in MySQL 4.1 or
-        later. Spatial column types are described in
+        later. Spatial data types are described in
         <xref linkend="spatial-extensions"/>.
       </para>
 
@@ -1409,7 +1408,7 @@
       <para>
         For general information on the properties of the various column
         types, see <xref linkend="data-types"/>. For information about
-        spatial column types, see <xref linkend="spatial-extensions"/>.
+        spatial data types, see <xref linkend="spatial-extensions"/>.
       </para>
 
       <itemizedlist>
@@ -1906,7 +1905,7 @@
         <listitem>
           <para>
             In MySQL 4.1 or later, you can create
-            <literal>SPATIAL</literal> indexes on spatial column types.
+            <literal>SPATIAL</literal> indexes on spatial data types.
             Spatial types are supported only for
             <literal>MyISAM</literal> tables and indexed columns must be
             declared as <literal>NOT NULL</literal>. See
@@ -2559,7 +2558,7 @@
 </programlisting>
 
       <para>
-        Some conversion of column types might occur. For example, the
+        Some conversion of data types might occur. For example, the
         <literal>AUTO_INCREMENT</literal> attribute is not preserved,
         and <literal>VARCHAR</literal> columns can become
         <literal>CHAR</literal> columns.
@@ -2712,7 +2711,7 @@
             <para>
               <literal>TIMESTAMP</literal> display sizes are discarded
               from MySQL 4.1 on, due to changes made to the
-              <literal>TIMESTAMP</literal> column type in that version.
+              <literal>TIMESTAMP</literal> data type in that version.
               Before MySQL 4.1, <literal>TIMESTAMP</literal> display
               sizes must be even and in the range from 2 to 14. If you
               specify a display size of 0 or greater than 14, the size
@@ -2756,7 +2755,7 @@
 
           <listitem>
             <para>
-              MySQL maps certain column types used by other SQL database
+              MySQL maps certain data types used by other SQL database
               vendors to MySQL types. See
               <xref linkend="other-vendor-data-types"/>.
             </para>
@@ -2775,7 +2774,7 @@
         </itemizedlist>
 
         <para>
-          To see whether MySQL used a column type other than the one you
+          To see whether MySQL used a data type other than the one you
           specified, issue a <literal>DESCRIBE</literal> or
           <literal>SHOW CREATE TABLE</literal> statement after creating
           or altering the table.
@@ -2786,7 +2785,7 @@
         </indexterm>
 
         <para>
-          Certain other column type changes can occur if you compress a
+          Certain other data type changes can occur if you compress a
           table using <command>myisampack</command>. See
           <xref linkend="compressed-format"/>.
         </para>
@@ -3970,7 +3969,7 @@
             This might involve type conversion if the type of the
             expression does not match the type of the column, and
             conversion of a given value can result in different inserted
-            values depending on the column type. For example, inserting
+            values depending on the data type. For example, inserting
             the string <literal>'1999.0e-2'</literal> into an
             <literal>INT</literal>, <literal>FLOAT</literal>,
             <literal>DECIMAL(10,6)</literal>, or <literal>YEAR</literal>
@@ -4292,8 +4291,8 @@
         <listitem>
           <para>
             Inserting a value into a date or time column that is illegal
-            for the column type. The column is set to the appropriate
-            zero value for the type.
+            for the data type. The column is set to the appropriate zero
+            value for the type.
           </para>
         </listitem>
 
@@ -8934,7 +8933,7 @@
       <para>
         If you update a column that has been declared <literal>NOT
         NULL</literal> by setting to <literal>NULL</literal>, the column
-        is set to the default value appropriate for the column type and
+        is set to the default value appropriate for the data type and
         the warning count is incremented. The default value is
         <literal>0</literal> for numeric types, the empty string
         (<literal>''</literal>) for string types, and the
@@ -9164,9 +9163,9 @@
       </para>
 
       <para>
-        If the column types are different from what you expect them to
-        be based on a <literal>CREATE TABLE</literal> statement, note
-        that MySQL sometimes changes column types. See
+        If the data types are different from what you expect them to be
+        based on a <literal>CREATE TABLE</literal> statement, note that
+        MySQL sometimes changes data types. See
         <xref linkend="silent-column-changes"/>.
       </para>
 
@@ -13245,11 +13244,11 @@
         </para>
 
         <para>
-          If the column types differ from what you expect them to be
-          based on your <literal>CREATE TABLE</literal> statement, note
-          that MySQL sometimes changes column types when you create or
-          alter a table. The conditions for which this occurs are
-          described in <xref linkend="silent-column-changes"/>.
+          If the data types differ from what you expect them to be based
+          on your <literal>CREATE TABLE</literal> statement, note that
+          MySQL sometimes changes data types when you create or alter a
+          table. The conditions for which this occurs are described in
+          <xref linkend="silent-column-changes"/>.
         </para>
 
         <para>
@@ -14503,9 +14502,9 @@
                 <literal>Repair by sorting</literal>, <literal>Repair
                 done</literal>, <literal>Repair with keycache</literal>,
                 <literal>Requesting binlog dump</literal>,
-                <literal>Rolling back</literal>,
-                <literal>Saving state</literal>, <literal>Searching rows
-                for update</literal>, <literal>Sending binlog event to
+                <literal>Rolling back</literal>, <literal>Saving
+                state</literal>, <literal>Searching rows for
+                update</literal>, <literal>Sending binlog event to
                 slave</literal>, <literal>Sending data</literal>,
                 <literal>Sorting for group</literal>, <literal>Sorting
                 for order</literal>, <literal>Sorting index</literal>,

Modified: trunk/refman-4.1/storage-engines.xml
===================================================================
--- trunk/refman-4.1/storage-engines.xml	2006-01-10 04:12:27 UTC (rev 750)
+++ trunk/refman-4.1/storage-engines.xml	2006-01-10 05:55:56 UTC (rev 751)
@@ -1296,8 +1296,7 @@
               <listitem>
                 <para>
                   If a column has only a small set of possible values,
-                  the column type is converted to
-                  <literal>ENUM</literal>.
+                  the data type is converted to <literal>ENUM</literal>.
                 </para>
               </listitem>
 

Modified: trunk/refman-4.1/tutorial.xml
===================================================================
--- trunk/refman-4.1/tutorial.xml	2006-01-10 04:12:27 UTC (rev 750)
+++ trunk/refman-4.1/tutorial.xml	2006-01-10 05:55:56 UTC (rev 751)
@@ -876,12 +876,13 @@
         <literal>VARCHAR</literal> is a good choice for the
         <literal>name</literal>, <literal>owner</literal>, and
         <literal>species</literal> columns because the column values
-        vary in length. The lengths of those columns need not all be the
-        same, and need not be <literal>20</literal>. You can pick any
-        length from <literal>1</literal> to <literal>255</literal>,
-        whatever seems most reasonable to you. (If you make a poor
-        choice and it turns out later that you need a longer field,
-        MySQL provides an <literal>ALTER TABLE</literal> statement.)
+        vary in length. The lengths in those column definitions need not
+        all be the same, and need not be <literal>20</literal>. You can
+        pick any length from <literal>1</literal> to
+        <literal>255</literal>, whatever seems most reasonable to you.
+        (If you make a poor choice and it turns out later that you need
+        a longer field, MySQL provides an <literal>ALTER TABLE</literal>
+        statement.)
       </para>
 
       <para>
@@ -937,6 +938,11 @@
         types they have.
       </para>
 
+      <para>
+        For more information about MySQL data types, see
+        <xref linkend="data-types"/>.
+      </para>
+
     </section>
 
     <section id="loading-tables">
@@ -3725,7 +3731,7 @@
 
       <title>&title-example-auto-increment;</title>
 
-      <remark role="help-category" condition="Column Types"/>
+      <remark role="help-category" condition="Data Types"/>
 
       <indexterm>
         <primary>AUTO_INCREMENT</primary>

Modified: trunk/refman-5.0/apis.xml
===================================================================
--- trunk/refman-5.0/apis.xml	2006-01-10 04:12:27 UTC (rev 750)
+++ trunk/refman-5.0/apis.xml	2006-01-10 05:55:56 UTC (rev 751)
@@ -8130,7 +8130,7 @@
                 For input, this is a pointer to the buffer in which a
                 statement parameter's data value is stored. For output,
                 it is a pointer to the buffer in which to return a
-                result set column value. For numeric column types,
+                result set column value. For numeric data types,
                 <literal>buffer</literal> should point to a variable of
                 the proper C type. (If you are associating the variable
                 with a column that has the <literal>UNSIGNED</literal>
@@ -8138,12 +8138,11 @@
                 <literal>unsigned</literal> C type. Indicate whether the
                 variable is signed or unsigned by using the
                 <literal>is_unsigned</literal> member, described later
-                in this list.) For date and time column types,
+                in this list.) For date and time data types,
                 <literal>buffer</literal> should point to a
                 <literal>MYSQL_TIME</literal> structure. For character
-                and binary string column types,
-                <literal>buffer</literal> should point to a character
-                buffer.
+                and binary string data types, <literal>buffer</literal>
+                should point to a character buffer.
               </para>
             </listitem>
 

Modified: trunk/refman-5.0/charset.xml
===================================================================
--- trunk/refman-5.0/charset.xml	2006-01-10 04:12:27 UTC (rev 750)
+++ trunk/refman-5.0/charset.xml	2006-01-10 05:55:56 UTC (rev 751)
@@ -2241,7 +2241,7 @@
       CHAR</literal> as a way to indicate that a <literal>CHAR</literal>
       column should use some predefined character set. MySQL
       &current-series; uses <literal>utf8</literal> as this predefined
-      character set. For example, these column type declarations are
+      character set. For example, these data type declarations are
       equivalent:
     </para>
 

Modified: trunk/refman-5.0/client-utility-programs.xml
===================================================================
--- trunk/refman-5.0/client-utility-programs.xml	2006-01-10 04:12:27 UTC (rev 750)
+++ trunk/refman-5.0/client-utility-programs.xml	2006-01-10 05:55:56 UTC (rev 751)
@@ -970,8 +970,8 @@
             </para>
 
             <para>
-              The column type. The value may contain any of the
-              following descriptors:
+              The data type. The value may contain any of the following
+              descriptors:
             </para>
 
             <itemizedlist>

Modified: trunk/refman-5.0/extending-mysql.xml
===================================================================
--- trunk/refman-5.0/extending-mysql.xml	2006-01-10 04:12:27 UTC (rev 750)
+++ trunk/refman-5.0/extending-mysql.xml	2006-01-10 05:55:56 UTC (rev 751)
@@ -1264,7 +1264,7 @@
               If you want to return a blob value, you can set
               <literal>max_length</literal> to 65KB or 16MB. This memory
               is not allocated, but the value is used to decide which
-              column type to use if there is a need to temporarily store
+              data type to use if there is a need to temporarily store
               the data.
             </para>
           </listitem>
@@ -2350,8 +2350,8 @@
             <replaceable>max_elements</replaceable> (default 256) is the
             maximum number of distinct values <literal>analyse</literal>
             does notice per column. This is used by
-            <literal>analyse</literal> to check whether the optimal
-            column type should be of type <literal>ENUM</literal>.
+            <literal>analyse</literal> to check whether the optimal data
+            type should be of type <literal>ENUM</literal>.
           </para>
         </listitem>
 

Modified: trunk/refman-5.0/functions.xml
===================================================================
--- trunk/refman-5.0/functions.xml	2006-01-10 04:12:27 UTC (rev 750)
+++ trunk/refman-5.0/functions.xml	2006-01-10 05:55:56 UTC (rev 751)
@@ -11706,7 +11706,7 @@
           <para>
             The result is a binary string of the same length as
             <replaceable>str</replaceable>. If you want to save it in a
-            column, use a <literal>BLOB</literal> column type.
+            column, use a <literal>BLOB</literal> data type.
           </para>
 
           <remark role="help-description-end"/>

Modified: trunk/refman-5.0/innodb.xml
===================================================================
--- trunk/refman-5.0/innodb.xml	2006-01-10 04:12:27 UTC (rev 750)
+++ trunk/refman-5.0/innodb.xml	2006-01-10 05:55:56 UTC (rev 751)
@@ -2299,14 +2299,13 @@
 
         <listitem>
           <para>
-            <literal>NO ACTION</literal>: In <literal>ANSI
-            SQL-92</literal> standard, <literal>NO ACTION</literal>
-            means <emphasis>no action</emphasis> in the sense that an
-            attempt to delete or update a primary key value is not
-            allowed to proceed if there is a related foreign key value
-            in the referenced table (Gruber, <citetitle>Mastering
-            SQL</citetitle>, 2000:181). <literal>InnoDB</literal>
-            rejects the delete or update operation for the parent table.
+            <literal>NO ACTION</literal>: In standard SQL, <literal>NO
+            ACTION</literal> means <emphasis>no action</emphasis> in the
+            sense that an attempt to delete or update a primary key
+            value is not allowed to proceed if there is a related
+            foreign key value in the referenced table.
+            <literal>InnoDB</literal> rejects the delete or update
+            operation for the parent table.
           </para>
         </listitem>
 
@@ -3048,7 +3047,9 @@
       If your database gets corrupted or your disk fails, you have to do
       the recovery from a backup. In the case of corruption, you should
       first find a backup that is not corrupted. After restoring the
-      base backup, do the recovery from the binary log files.
+      base backup, do the recovery from the binary log files using
+      <command>mysqlbinlog</command> and <command>mysql</command> to
+      restore the changes performed after the backup was made.
     </para>
 
     <para>
@@ -3066,8 +3067,8 @@
       In some cases, apparent database page corruption is actually due
       to the operating system corrupting its own file cache, and the
       data on disk may be okay. It is best first to try restarting your
-      computer. It may eliminate errors that appeared to be database
-      page corruption.
+      computer. Doing so may eliminate errors that appeared to be
+      database page corruption.
     </para>
 
     <section id="forcing-recovery">
@@ -3077,12 +3078,12 @@
       <para>
         If there is database page corruption, you may want to dump your
         tables from the database with <literal>SELECT INTO
-        OUTFILE</literal>; usually, most of the data obtained in this
+        OUTFILE</literal>. Usually, most of the data obtained in this
         way is intact. Even so, the corruption may cause <literal>SELECT
-        * FROM <replaceable>tbl_name</replaceable></literal> or
-        <literal>InnoDB</literal> background operations to crash or
+        * FROM <replaceable>tbl_name</replaceable></literal> statements
+        or <literal>InnoDB</literal> background operations to crash or
         assert, or even make <literal>InnoDB</literal> roll-forward
-        recovery crash. However, you can use to force the
+        recovery crash. However, you can force the
         <literal>InnoDB</literal> storage engine to start up while
         preventing background operations from running, so that you are
         able to dump your tables. For example, you can add the following
@@ -3098,11 +3099,11 @@
       <para>
         The allowable non-zero values for
         <literal>innodb_force_recovery</literal> follow. A larger number
-        includes all precautions of lower numbers. If you are able to
+        includes all precautions of smaller numbers. If you are able to
         dump your tables with an option value of at most 4, then you are
         relatively safe that only some data on corrupt individual pages
-        is lost. A value of 6 is more dramatic, because database pages
-        are left in an obsolete state, which in turn may introduce more
+        is lost. A value of 6 is more drastic because database pages are
+        left in an obsolete state, which in turn may introduce more
         corruption into B-trees and other database structures.
       </para>
 
@@ -3115,7 +3116,7 @@
           </para>
 
           <para>
-            Let the server run even if it detects a corrupt page; try to
+            Let the server run even if it detects a corrupt page. Try to
             make <literal>SELECT * FROM
             <replaceable>tbl_name</replaceable></literal> jump over
             corrupt index records and pages, which helps in dumping
@@ -3131,7 +3132,7 @@
 
           <para>
             Prevent the main thread from running. If a crash would occur
-            during the purge operation, this prevents it.
+            during the purge operation, this recovery value prevents it.
           </para>
         </listitem>
 
@@ -3154,7 +3155,7 @@
 
           <para>
             Prevent also insert buffer merge operations. If they would
-            cause a crash, better not do them; do not calculate table
+            cause a crash, do not do them. Do not calculate table
             statistics.
           </para>
         </listitem>
@@ -3186,21 +3187,12 @@
       </itemizedlist>
 
       <para>
-        <emphasis>The database must not otherwise be used with any of
-        these options enabled</emphasis>. As a safety measure,
-        <literal>InnoDB</literal> prevents users from performing
-        <literal>INSERT</literal>, <literal>UPDATE</literal>, or
-        <literal>DELETE</literal> operations when
-        <literal>innodb_force_recovery</literal> is set to a value
-        greater than 0.
-      </para>
-
-      <para>
-        You may <literal>DROP</literal> or <literal>CREATE</literal>
-        tables even if forced recovery is used. If you know that a given
-        table is causing a crash on rollback, you can drop it. You can
-        also use this to stop a runaway rollback caused by a failing
-        mass import or <literal>ALTER TABLE</literal>. You can kill the
+        You can <literal>SELECT</literal> from tables to dump them, or
+        <literal>DROP</literal> or <literal>CREATE</literal> tables even
+        if forced recovery is used. If you know that a given table is
+        causing a crash on rollback, you can drop it. You can also use
+        this to stop a runaway rollback caused by a failing mass import
+        or <literal>ALTER TABLE</literal>. You can kill the
         <command>mysqld</command> process and set
         <literal>innodb_force_recovery</literal> to <literal>3</literal>
         to bring the database up without the rollback, then
@@ -3208,6 +3200,16 @@
         rollback.
       </para>
 
+      <para>
+        <emphasis>The database must not otherwise be used with any
+        non-zero value of
+        <literal>innodb_force_recovery</literal></emphasis>. As a safety
+        measure, <literal>InnoDB</literal> prevents users from
+        performing <literal>INSERT</literal>, <literal>UPDATE</literal>,
+        or <literal>DELETE</literal> operations when
+        <literal>innodb_force_recovery</literal> is greater than 0.
+      </para>
+
     </section>
 
     <section id="innodb-checkpoints">
@@ -3234,26 +3236,26 @@
       </para>
 
       <para>
-        <literal>InnoDB</literal> writes to the log files on a rotating
+        <literal>InnoDB</literal> writes to its log files on a rotating
         basis. All committed modifications that make the database pages
         in the buffer pool different from the images on disk must be
         available in the log files in case <literal>InnoDB</literal> has
         to do a recovery. This means that when <literal>InnoDB</literal>
         starts to reuse a log file, it has to make sure that the
         database page images on disk contain the modifications logged in
-        the log file <literal>InnoDB</literal> is going to reuse. In
-        other words, <literal>InnoDB</literal> must create a checkpoint
-        and this often involves flushing of modified database pages to
-        disk.
+        the log file that <literal>InnoDB</literal> is going to reuse.
+        In other words, <literal>InnoDB</literal> must create a
+        checkpoint and this often involves flushing of modified database
+        pages to disk.
       </para>
 
       <para>
         The preceding description explains why making your log files
         very large may save disk I/O in checkpointing. It often makes
         sense to set the total size of the log files as big as the
-        buffer pool or even bigger. The drawback of big log files is
-        that crash recovery can take longer because there is more logged
-        information to apply to the database.
+        buffer pool or even bigger. The drawback of using large log
+        files is that crash recovery can take longer because there is
+        more logged information to apply to the database.
       </para>
 
     </section>
@@ -3271,8 +3273,8 @@
       have all table and database names in lowercase. A convenient way
       to accomplish this is to add the following line to the
       <literal>[mysqld]</literal> section of your
-      <filename>my.cnf</filename> or <filename>my.ini</filename> before
-      creating any databases or tables:
+      <filename>my.cnf</filename> or <filename>my.ini</filename> file
+      before creating any databases or tables:
     </para>
 
 <programlisting>
@@ -3310,9 +3312,9 @@
     <title>&title-innodb-transaction-model;</title>
 
     <para>
-      In the <literal>InnoDB</literal> transaction model, the goal has
-      been to combine the best properties of a multi-versioning database
-      with traditional two-phase locking. <literal>InnoDB</literal> does
+      In the <literal>InnoDB</literal> transaction model, the goal is to
+      combine the best properties of a multi-versioning database with
+      traditional two-phase locking. <literal>InnoDB</literal> does
       locking on the row level and runs queries as non-locking
       consistent reads by default, in the style of Oracle. The lock
       table in <literal>InnoDB</literal> is stored so space-efficiently
@@ -3349,20 +3351,9 @@
       </itemizedlist>
 
       <para>
-        If a transaction <replaceable>A</replaceable> holds an exclusive
-        (<replaceable>X</replaceable>) lock on tuple
-        <replaceable>t</replaceable>, then a request from some distinct
-        transaction <replaceable>B</replaceable> for a lock of either
-        type on <replaceable>t</replaceable> cannot be granted
-        immediately. Instead, transaction <replaceable>B</replaceable>
-        has to wait for transaction <replaceable>A</replaceable> to
-        release its lock on tuple <replaceable>t</replaceable>.
-      </para>
-
-      <para>
-        If transaction <replaceable>A</replaceable> holds a shared
+        If transaction <literal>T1</literal> holds a shared
         (<replaceable>S</replaceable>) lock on tuple
-        <replaceable>t</replaceable>, then
+        <literal>t</literal>, then
       </para>
 
       <itemizedlist>
@@ -3370,41 +3361,49 @@
         <listitem>
           <para>
             A request from some distinct transaction
-            <replaceable>B</replaceable> for an
-            <replaceable>X</replaceable> lock on
-            <replaceable>t</replaceable> cannot be granted immediately.
+            <literal>T2</literal> for an <replaceable>S</replaceable>
+            lock on <literal>t</literal> can be granted immediately. As
+            a result, both <literal>T1</literal> and
+            <literal>T2</literal> hold an <replaceable>S</replaceable>
+            lock on <literal>t</literal>.
           </para>
         </listitem>
 
         <listitem>
           <para>
             A request from some distinct transaction
-            <replaceable>B</replaceable> for an
-            <replaceable>S</replaceable> lock on
-            <replaceable>t</replaceable> can be granted immediately. As
-            a result, both <replaceable>A</replaceable> and
-            <replaceable>B</replaceable> hold an
-            <replaceable>S</replaceable> lock on
-            <replaceable>t</replaceable>.
+            <literal>T2</literal> for an <replaceable>X</replaceable>
+            lock on <literal>t</literal> cannot be granted immediately.
           </para>
         </listitem>
 
       </itemizedlist>
 
       <para>
+        If a transaction <literal>T1</literal> holds an exclusive
+        (<replaceable>X</replaceable>) lock on tuple
+        <literal>t</literal>, then a request from some distinct
+        transaction <literal>T2</literal> for a lock of either type on
+        <literal>t</literal> cannot be granted immediately. Instead,
+        transaction <literal>T2</literal> has to wait for transaction
+        <literal>T1</literal> to release its lock on tuple
+        <literal>t</literal>.
+      </para>
+
+      <para>
         Additionally, <literal>InnoDB</literal> supports
         <emphasis>multiple granularity locking</emphasis> which allows
         coexistence of record locks and locks on entire tables. To make
         locking at multiple granularity levels practical, additional
-        types of locks, called <emphasis>intention locks</emphasis> are
+        types of locks called <emphasis>intention locks</emphasis> are
         used. Intention locks are table locks in
         <literal>InnoDB</literal>. The idea behind intention locks is
         for a transaction to indicate which type of lock (shared or
         exclusive) it will require later for a row in that table. There
         are two types of intention locks used in
         <literal>InnoDB</literal> (assume that transaction
-        <replaceable>T</replaceable> has requested a lock of the
-        indicated type on table <replaceable>R</replaceable>):
+        <literal>T</literal> has requested a lock of the indicated type
+        on table <literal>R</literal>):
       </para>
 
       <itemizedlist>
@@ -3412,17 +3411,17 @@
         <listitem>
           <para>
             Intention shared (<replaceable>IS</replaceable>):
-            Transaction <replaceable>T</replaceable> intends to set
-            <replaceable>S</replaceable> locks on individual tuples in
-            table <replaceable>T</replaceable>.
+            Transaction <literal>T</literal> intends to set
+            <replaceable>S</replaceable> locks on individual rows in
+            table <literal>R</literal>.
           </para>
         </listitem>
 
         <listitem>
           <para>
             Intention exclusive (<replaceable>IX</replaceable>):
-            Transaction <replaceable>T</replaceable> intends to set
-            <replaceable>X</replaceable> locks on those tuples.
+            Transaction <literal>T</literal> intends to set
+            <replaceable>X</replaceable> locks on those rows.
           </para>
         </listitem>
 
@@ -3462,41 +3461,41 @@
       <informaltable>
         <tgroup cols="5">
           <colspec colwidth="20*"/>
-          <colspec colwidth="10*"/>
-          <colspec colwidth="10*"/>
-          <colspec colwidth="10*"/>
-          <colspec colwidth="10*"/>
+          <colspec colwidth="20*"/>
+          <colspec colwidth="20*"/>
+          <colspec colwidth="20*"/>
+          <colspec colwidth="20*"/>
           <tbody>
             <row>
               <entry/>
-              <entry>X</entry>
-              <entry>IX</entry>
-              <entry>S</entry>
-              <entry>IS</entry>
+              <entry><replaceable>X</replaceable></entry>
+              <entry><replaceable>IX</replaceable></entry>
+              <entry><replaceable>S</replaceable></entry>
+              <entry><replaceable>IS</replaceable></entry>
             </row>
             <row>
-              <entry>X</entry>
+              <entry><replaceable>X</replaceable></entry>
               <entry>Conflict</entry>
               <entry>Conflict</entry>
               <entry>Conflict</entry>
               <entry>Conflict</entry>
             </row>
             <row>
-              <entry>IX</entry>
+              <entry><replaceable>IX</replaceable></entry>
               <entry>Conflict</entry>
               <entry>Compatible</entry>
               <entry>Conflict</entry>
               <entry>Compatible</entry>
             </row>
             <row>
-              <entry>S</entry>
+              <entry><replaceable>S</replaceable></entry>
               <entry>Conflict</entry>
               <entry>Conflict</entry>
               <entry>Compatible</entry>
               <entry>Compatible</entry>
             </row>
             <row>
-              <entry>IS</entry>
+              <entry><replaceable>IS</replaceable></entry>
               <entry>Conflict</entry>
               <entry>Compatible</entry>
               <entry>Compatible</entry>
@@ -4644,7 +4643,7 @@
 
       <listitem>
         <para>
-          Use the <literal>VARCHAR</literal> column type instead of
+          Use the <literal>VARCHAR</literal> data type instead of
           <literal>CHAR</literal> if you are storing variable-length
           strings or if the column may contain many
           <literal>NULL</literal> values. A

Modified: trunk/refman-5.0/installing.xml
===================================================================
--- trunk/refman-5.0/installing.xml	2006-01-10 04:12:27 UTC (rev 750)
+++ trunk/refman-5.0/installing.xml	2006-01-10 05:55:56 UTC (rev 751)
@@ -12090,7 +12090,7 @@
             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,
+            floating-point data not strictly legal for the data type,
             you should alter the data types of those columns. For
             example:
           </para>
@@ -12471,8 +12471,8 @@
             <literal>ALTER TABLE</literal> on it. The <literal>ALTER
             TABLE</literal> also will change the table's
             <literal>VARCHAR</literal> columns to use the new
-            <literal>VARCHAR</literal> column type. For information
-            about possible incompatibilities with old applications, see
+            <literal>VARCHAR</literal> data type. For information about
+            possible incompatibilities with old applications, see
             <xref linkend="precision-math"/>.
           </para>
         </listitem>

Modified: trunk/refman-5.0/ndbcluster.xml
===================================================================
--- trunk/refman-5.0/ndbcluster.xml	2006-01-10 04:12:27 UTC (rev 750)
+++ trunk/refman-5.0/ndbcluster.xml	2006-01-10 05:55:56 UTC (rev 751)
@@ -10324,13 +10324,13 @@
 
       <listitem>
         <para>
-          <emphasis>What column types are supported by MySQL
+          <emphasis>What data types are supported by MySQL
           Cluster?</emphasis>
         </para>
 
         <para>
-          MySQL Cluster supports all of the usual MySQL column types,
-          with the exception of those associated with MySQL's spatial
+          MySQL Cluster supports all of the usual MySQL data types, with
+          the exception of those associated with MySQL's spatial
           extensions. (See <xref linkend="spatial-extensions"/>.) In
           addition, there are some differences with regard to indexes
           when used with <literal>NDB</literal> tables.
@@ -10949,7 +10949,7 @@
           <emphasis role="bold">D</emphasis>ata<emphasis role="bold">b</emphasis>ase,
           and refers to the storage engine used to enable MySQL Cluster.
           The <literal>NDB</literal> storage engine supports all the
-          usual MySQL column types and SQL statements, and is
+          usual MySQL data types and SQL statements, and is
           ACID-compliant. This engine also provides full support for
           transactions (commits and rollbacks).
         </para>

Modified: trunk/refman-5.0/optimization.xml
===================================================================
--- trunk/refman-5.0/optimization.xml	2006-01-10 04:12:27 UTC (rev 750)
+++ trunk/refman-5.0/optimization.xml	2006-01-10 05:55:56 UTC (rev 751)
@@ -502,7 +502,7 @@
 
         <listitem>
           <para>
-            What column types are supported
+            What data types are supported
           </para>
         </listitem>
 
@@ -1750,7 +1750,7 @@
                 <row>
                   <entry><emphasis role="bold">Table</emphasis></entry>
                   <entry><emphasis role="bold">Column</emphasis></entry>
-                  <entry><emphasis role="bold">Column Type</emphasis></entry>
+                  <entry><emphasis role="bold">Data Type</emphasis></entry>
                 </row>
                 <row>
                   <entry><literal>tt</literal></entry>
@@ -6784,7 +6784,7 @@
       </indexterm>
 
       <para>
-        All MySQL column types can be indexed. Use of indexes on the
+        All MySQL data types can be indexed. Use of indexes on the
         relevant columns is the best way to improve the performance of
         <literal>SELECT</literal> operations.
       </para>
@@ -6862,9 +6862,9 @@
       </para>
 
       <para>
-        You can also create indexes on spatial column types. Spatial
-        types are supported only by the <literal>MyISAM</literal>
-        storage engine. Spatial indexes use R-trees.
+        You can also create indexes on spatial data types. Spatial types
+        are supported only by the <literal>MyISAM</literal> storage
+        engine. Spatial indexes use R-trees.
       </para>
 
       <para>
@@ -6895,7 +6895,7 @@
 
       <para>
         MySQL can create indexes on multiple columns. An index may
-        consist of up to 15 columns. For certain column types, you can
+        consist of up to 15 columns. For certain data types, you can
         index a prefix of the column (see <xref linkend="indexes"/>).
       </para>
 
@@ -6998,7 +6998,7 @@
         Most MySQL indexes (<literal>PRIMARY KEY</literal>,
         <literal>UNIQUE</literal>, <literal>INDEX</literal>, and
         <literal>FULLTEXT</literal>) are stored in B-trees. Exceptions
-        are that indexes on spatial column types use R-trees, and that
+        are that indexes on spatial data types use R-trees, and that
         <literal>MEMORY</literal> tables also support hash indexes.
       </para>
 

Modified: trunk/refman-5.0/problems.xml
===================================================================
--- trunk/refman-5.0/problems.xml	2006-01-10 04:12:27 UTC (rev 750)
+++ trunk/refman-5.0/problems.xml	2006-01-10 05:55:56 UTC (rev 751)
@@ -3707,7 +3707,7 @@
       </indexterm>
 
       <para>
-        For some column types, MySQL handles <literal>NULL</literal>
+        For some data types, MySQL handles <literal>NULL</literal>
         values specially. If you insert <literal>NULL</literal> into a
         <literal>TIMESTAMP</literal> column, the current date and time
         is inserted. If you insert <literal>NULL</literal> into an
@@ -4005,7 +4005,7 @@
         Floating-point numbers sometimes cause confusion because they
         are not stored as exact values inside computer architecture.
         What you can see on the screen usually is not the exact value of
-        the number. The column types <literal>FLOAT</literal>,
+        the number. The data types <literal>FLOAT</literal>,
         <literal>DOUBLE</literal>, and <literal>DECIMAL</literal> are
         such. <literal>DECIMAL</literal> columns store values with exact
         precision because they are represented as strings, but
@@ -4016,11 +4016,10 @@
       <para>
         The following example (for older MySQL version than 5.0.3)
         demonstrate the problem. It shows that even for the
-        <literal>DECIMAL</literal> column type, calculations that are
-        done using floating-point operations are subject to
-        floating-point error. (In all MySQL versions, you would have
-        similar problems if you would replace the
-        <literal>DECIMAL</literal> columns with
+        <literal>DECIMAL</literal> data type, calculations that are done
+        using floating-point operations are subject to floating-point
+        error. (In all MySQL versions, you would have similar problems
+        if you would replace the <literal>DECIMAL</literal> columns with
         <literal>FLOAT</literal>).
       </para>
 

Modified: trunk/refman-5.0/sql-syntax.xml
===================================================================
--- trunk/refman-5.0/sql-syntax.xml	2006-01-10 04:12:27 UTC (rev 750)
+++ trunk/refman-5.0/sql-syntax.xml	2006-01-10 05:55:56 UTC (rev 751)
@@ -312,7 +312,7 @@
             same syntax for <literal>ADD</literal> and
             <literal>CHANGE</literal> as for <literal>CREATE
             TABLE</literal>. Note that this syntax includes the column
-            name, not just the column type. See
+            name, not just its data type. See
             <xref linkend="create-table"/>.
           </para>
         </listitem>
@@ -365,10 +365,9 @@
 
         <listitem>
           <para>
-            When you change a column type using
-            <literal>CHANGE</literal> or <literal>MODIFY</literal>,
-            MySQL tries to convert existing column values to the new
-            type as well as possible.
+            When you change a data type using <literal>CHANGE</literal>
+            or <literal>MODIFY</literal>, MySQL tries to convert
+            existing column values to the new type as well as possible.
           </para>
         </listitem>
 
@@ -1199,7 +1198,7 @@
       <para>
         <literal>SPATIAL</literal> indexes can include only spatial
         columns, and only in <literal>MyISAM</literal> tables. Spatial
-        column types are described in
+        data types are described in
         <xref linkend="spatial-extensions"/>.
       </para>
 
@@ -1421,7 +1420,7 @@
       <para>
         For general information on the properties of the various column
         types, see <xref linkend="data-types"/>. For information about
-        spatial column types, see <xref linkend="spatial-extensions"/>.
+        spatial data types, see <xref linkend="spatial-extensions"/>.
       </para>
 
       <itemizedlist>
@@ -1991,7 +1990,7 @@
         <listitem>
           <para>
             You can create <literal>SPATIAL</literal> indexes on spatial
-            column types. Spatial types are supported only for
+            data types. Spatial types are supported only for
             <literal>MyISAM</literal> tables and indexed columns must be
             declared as <literal>NOT NULL</literal>. See
             <xref linkend="spatial-extensions"/>.
@@ -2608,7 +2607,7 @@
 </programlisting>
 
       <para>
-        Some conversion of column types might occur. For example, the
+        Some conversion of data types might occur. For example, the
         <literal>AUTO_INCREMENT</literal> attribute is not preserved,
         and <literal>VARCHAR</literal> columns can become
         <literal>CHAR</literal> columns.
@@ -2800,7 +2799,7 @@
 
           <listitem>
             <para>
-              MySQL maps certain column types used by other SQL database
+              MySQL maps certain data types used by other SQL database
               vendors to MySQL types. See
               <xref linkend="other-vendor-data-types"/>.
             </para>
@@ -2819,7 +2818,7 @@
         </itemizedlist>
 
         <para>
-          To see whether MySQL used a column type other than the one you
+          To see whether MySQL used a data type other than the one you
           specified, issue a <literal>DESCRIBE</literal> or
           <literal>SHOW CREATE TABLE</literal> statement after creating
           or altering the table.
@@ -2830,7 +2829,7 @@
         </indexterm>
 
         <para>
-          Certain other column type changes can occur if you compress a
+          Certain other data type changes can occur if you compress a
           table using <command>myisampack</command>. See
           <xref linkend="compressed-format"/>.
         </para>
@@ -3982,7 +3981,7 @@
             This might involve type conversion if the type of the
             expression does not match the type of the column, and
             conversion of a given value can result in different inserted
-            values depending on the column type. For example, inserting
+            values depending on the data type. For example, inserting
             the string <literal>'1999.0e-2'</literal> into an
             <literal>INT</literal>, <literal>FLOAT</literal>,
             <literal>DECIMAL(10,6)</literal>, or <literal>YEAR</literal>
@@ -4300,8 +4299,8 @@
         <listitem>
           <para>
             Inserting a value into a date or time column that is illegal
-            for the column type. The column is set to the appropriate
-            zero value for the type.
+            for the data type. The column is set to the appropriate zero
+            value for the type.
           </para>
         </listitem>
 
@@ -9365,7 +9364,7 @@
       <para>
         If you update a column that has been declared <literal>NOT
         NULL</literal> by setting to <literal>NULL</literal>, the column
-        is set to the default value appropriate for the column type and
+        is set to the default value appropriate for the data type and
         the warning count is incremented. The default value is
         <literal>0</literal> for numeric types, the empty string
         (<literal>''</literal>) for string types, and the
@@ -9578,9 +9577,9 @@
       </para>
 
       <para>
-        If the column types are different from what you expect them to
-        be based on a <literal>CREATE TABLE</literal> statement, note
-        that MySQL sometimes changes column types. See
+        If the data types are different from what you expect them to be
+        based on a <literal>CREATE TABLE</literal> statement, note that
+        MySQL sometimes changes data types. See
         <xref linkend="silent-column-changes"/>.
       </para>
 
@@ -14536,11 +14535,11 @@
         </para>
 
         <para>
-          If the column types differ from what you expect them to be
-          based on your <literal>CREATE TABLE</literal> statement, note
-          that MySQL sometimes changes column types when you create or
-          alter a table. The conditions for which this occurs are
-          described in <xref linkend="silent-column-changes"/>.
+          If the data types differ from what you expect them to be based
+          on your <literal>CREATE TABLE</literal> statement, note that
+          MySQL sometimes changes data types when you create or alter a
+          table. The conditions for which this occurs are described in
+          <xref linkend="silent-column-changes"/>.
         </para>
 
         <para>
@@ -15802,9 +15801,9 @@
                 <literal>Repair by sorting</literal>, <literal>Repair
                 done</literal>, <literal>Repair with keycache</literal>,
                 <literal>Requesting binlog dump</literal>,
-                <literal>Rolling back</literal>,
-                <literal>Saving state</literal>, <literal>Searching rows
-                for update</literal>, <literal>Sending binlog event to
+                <literal>Rolling back</literal>, <literal>Saving
+                state</literal>, <literal>Searching rows for
+                update</literal>, <literal>Sending binlog event to
                 slave</literal>, <literal>Sending data</literal>,
                 <literal>Sorting for group</literal>, <literal>Sorting
                 for order</literal>, <literal>Sorting index</literal>,

Modified: trunk/refman-5.0/storage-engines.xml
===================================================================
--- trunk/refman-5.0/storage-engines.xml	2006-01-10 04:12:27 UTC (rev 750)
+++ trunk/refman-5.0/storage-engines.xml	2006-01-10 05:55:56 UTC (rev 751)
@@ -1319,8 +1319,7 @@
               <listitem>
                 <para>
                   If a column has only a small set of possible values,
-                  the column type is converted to
-                  <literal>ENUM</literal>.
+                  the data type is converted to <literal>ENUM</literal>.
                 </para>
               </listitem>
 

Modified: trunk/refman-5.0/tutorial.xml
===================================================================
--- trunk/refman-5.0/tutorial.xml	2006-01-10 04:12:27 UTC (rev 750)
+++ trunk/refman-5.0/tutorial.xml	2006-01-10 05:55:56 UTC (rev 751)
@@ -878,9 +878,9 @@
         <literal>VARCHAR</literal> is a good choice for the
         <literal>name</literal>, <literal>owner</literal>, and
         <literal>species</literal> columns because the column values
-        vary in length. The lengths of those columns need not all be the
-        same, and need not be <literal>20</literal>. You can normally
-        pick any length from <literal>1</literal> to
+        vary in length. The lengths in those column definitions need not
+        all be the same, and need not be <literal>20</literal>. You can
+        normally pick any length from <literal>1</literal> to
         <literal>65535</literal>, whatever seems most reasonable to you.
         (<emphasis role="bold">Note</emphasis>: Prior to MySQL 5.0.3,
         the upper limit was 255.) If you make a poor choice and it turns
@@ -941,6 +941,11 @@
         types they have.
       </para>
 
+      <para>
+        For more information about MySQL data types, see
+        <xref linkend="data-types"/>.
+      </para>
+
     </section>
 
     <section id="loading-tables">
@@ -3568,7 +3573,7 @@
 
       <title>&title-example-auto-increment;</title>
 
-      <remark role="help-category" condition="Column Types"/>
+      <remark role="help-category" condition="Data Types"/>
 
       <indexterm>
         <primary>AUTO_INCREMENT</primary>

Modified: trunk/refman-5.1/apis.xml
===================================================================
--- trunk/refman-5.1/apis.xml	2006-01-10 04:12:27 UTC (rev 750)
+++ trunk/refman-5.1/apis.xml	2006-01-10 05:55:56 UTC (rev 751)
@@ -8135,7 +8135,7 @@
                 For input, this is a pointer to the buffer in which a
                 statement parameter's data value is stored. For output,
                 it is a pointer to the buffer in which to return a
-                result set column value. For numeric column types,
+                result set column value. For numeric data types,
                 <literal>buffer</literal> should point to a variable of
                 the proper C type. (If you are associating the variable
                 with a column that has the <literal>UNSIGNED</literal>
@@ -8143,12 +8143,11 @@
                 <literal>unsigned</literal> C type. Indicate whether the
                 variable is signed or unsigned by using the
                 <literal>is_unsigned</literal> member, described later
-                in this list.) For date and time column types,
+                in this list.) For date and time data types,
                 <literal>buffer</literal> should point to a
                 <literal>MYSQL_TIME</literal> structure. For character
-                and binary string column types,
-                <literal>buffer</literal> should point to a character
-                buffer.
+                and binary string data types, <literal>buffer</literal>
+                should point to a character buffer.
               </para>
             </listitem>
 

Modified: trunk/refman-5.1/charset.xml
===================================================================
--- trunk/refman-5.1/charset.xml	2006-01-10 04:12:27 UTC (rev 750)
+++ trunk/refman-5.1/charset.xml	2006-01-10 05:55:56 UTC (rev 751)
@@ -2240,7 +2240,7 @@
       CHAR</literal> as a way to indicate that a <literal>CHAR</literal>
       column should use some predefined character set. MySQL
       &current-series; uses <literal>utf8</literal> as this predefined
-      character set. For example, these column type declarations are
+      character set. For example, these data type declarations are
       equivalent:
     </para>
 

Modified: trunk/refman-5.1/client-utility-programs.xml
===================================================================
--- trunk/refman-5.1/client-utility-programs.xml	2006-01-10 04:12:27 UTC (rev 750)
+++ trunk/refman-5.1/client-utility-programs.xml	2006-01-10 05:55:56 UTC (rev 751)
@@ -970,8 +970,8 @@
             </para>
 
             <para>
-              The column type. The value may contain any of the
-              following descriptors:
+              The data type. The value may contain any of the following
+              descriptors:
             </para>
 
             <itemizedlist>

Modified: trunk/refman-5.1/custom-engine.xml
===================================================================
--- trunk/refman-5.1/custom-engine.xml	2006-01-10 04:12:27 UTC (rev 750)
+++ trunk/refman-5.1/custom-engine.xml	2006-01-10 05:55:56 UTC (rev 751)
@@ -1288,9 +1288,8 @@
 
       <para>
         After the NULL bitmap come the columns, one by one. Each column
-        is of the size indicated in the Column Types section of the
-        MySQL manual (<xref linkend="data-types"/>). In the server,
-        column data types are defined in the
+        is of the size indicated in <xref linkend="data-types"/>. In the
+        server, column data types are defined in the
         <filename>sql/field.cc</filename> file. In the fixed length row
         format, the columns are simply laid out one by one. In a
         variable-length row, <literal>VARCHAR</literal> columns are

Modified: trunk/refman-5.1/extending-mysql.xml
===================================================================
--- trunk/refman-5.1/extending-mysql.xml	2006-01-10 04:12:27 UTC (rev 750)
+++ trunk/refman-5.1/extending-mysql.xml	2006-01-10 05:55:56 UTC (rev 751)
@@ -3062,7 +3062,7 @@
               If you want to return a blob value, you can set
               <literal>max_length</literal> to 65KB or 16MB. This memory
               is not allocated, but the value is used to decide which
-              column type to use if there is a need to temporarily store
+              data type to use if there is a need to temporarily store
               the data.
             </para>
           </listitem>
@@ -4122,8 +4122,8 @@
             <replaceable>max_elements</replaceable> (default 256) is the
             maximum number of distinct values <literal>analyse</literal>
             does notice per column. This is used by
-            <literal>analyse</literal> to check whether the optimal
-            column type should be of type <literal>ENUM</literal>.
+            <literal>analyse</literal> to check whether the optimal data
+            type should be of type <literal>ENUM</literal>.
           </para>
         </listitem>
 

Modified: trunk/refman-5.1/functions.xml
===================================================================
--- trunk/refman-5.1/functions.xml	2006-01-10 04:12:27 UTC (rev 750)
+++ trunk/refman-5.1/functions.xml	2006-01-10 05:55:56 UTC (rev 751)
@@ -11641,7 +11641,7 @@
           <para>
             The result is a binary string of the same length as
             <replaceable>str</replaceable>. If you want to save it in a
-            column, use a <literal>BLOB</literal> column type.
+            column, use a <literal>BLOB</literal> data type.
           </para>
 
           <remark role="help-description-end"/>

Modified: trunk/refman-5.1/innodb.xml
===================================================================
--- trunk/refman-5.1/innodb.xml	2006-01-10 04:12:27 UTC (rev 750)
+++ trunk/refman-5.1/innodb.xml	2006-01-10 05:55:56 UTC (rev 751)
@@ -2275,14 +2275,13 @@
 
         <listitem>
           <para>
-            <literal>NO ACTION</literal>: In <literal>ANSI
-            SQL-92</literal> standard, <literal>NO ACTION</literal>
-            means <emphasis>no action</emphasis> in the sense that an
-            attempt to delete or update a primary key value is not
-            allowed to proceed if there is a related foreign key value
-            in the referenced table (Gruber, <citetitle>Mastering
-            SQL</citetitle>, 2000:181). <literal>InnoDB</literal>
-            rejects the delete or update operation for the parent table.
+            <literal>NO ACTION</literal>: In standard SQL, <literal>NO
+            ACTION</literal> means <emphasis>no action</emphasis> in the
+            sense that an attempt to delete or update a primary key
+            value is not allowed to proceed if there is a related
+            foreign key value in the referenced table.
+            <literal>InnoDB</literal> rejects the delete or update
+            operation for the parent table.
           </para>
         </listitem>
 
@@ -3024,7 +3023,9 @@
       If your database gets corrupted or your disk fails, you have to do
       the recovery from a backup. In the case of corruption, you should
       first find a backup that is not corrupted. After restoring the
-      base backup, do the recovery from the binary log files.
+      base backup, do the recovery from the binary log files using
+      <command>mysqlbinlog</command> and <command>mysql</command> to
+      restore the changes performed after the backup was made.
     </para>
 
     <para>
@@ -3042,8 +3043,8 @@
       In some cases, apparent database page corruption is actually due
       to the operating system corrupting its own file cache, and the
       data on disk may be okay. It is best first to try restarting your
-      computer. It may eliminate errors that appeared to be database
-      page corruption.
+      computer. Doing so may eliminate errors that appeared to be
+      database page corruption.
     </para>
 
     <section id="forcing-recovery">
@@ -3053,12 +3054,12 @@
       <para>
         If there is database page corruption, you may want to dump your
         tables from the database with <literal>SELECT INTO
-        OUTFILE</literal>; usually, most of the data obtained in this
+        OUTFILE</literal>. Usually, most of the data obtained in this
         way is intact. Even so, the corruption may cause <literal>SELECT
-        * FROM <replaceable>tbl_name</replaceable></literal> or
-        <literal>InnoDB</literal> background operations to crash or
+        * FROM <replaceable>tbl_name</replaceable></literal> statements
+        or <literal>InnoDB</literal> background operations to crash or
         assert, or even make <literal>InnoDB</literal> roll-forward
-        recovery crash. However, you can use to force the
+        recovery crash. However, you can force the
         <literal>InnoDB</literal> storage engine to start up while
         preventing background operations from running, so that you are
         able to dump your tables. For example, you can add the following
@@ -3074,11 +3075,11 @@
       <para>
         The allowable non-zero values for
         <literal>innodb_force_recovery</literal> follow. A larger number
-        includes all precautions of lower numbers. If you are able to
+        includes all precautions of smaller numbers. If you are able to
         dump your tables with an option value of at most 4, then you are
         relatively safe that only some data on corrupt individual pages
-        is lost. A value of 6 is more dramatic, because database pages
-        are left in an obsolete state, which in turn may introduce more
+        is lost. A value of 6 is more drastic because database pages are
+        left in an obsolete state, which in turn may introduce more
         corruption into B-trees and other database structures.
       </para>
 
@@ -3091,7 +3092,7 @@
           </para>
 
           <para>
-            Let the server run even if it detects a corrupt page; try to
+            Let the server run even if it detects a corrupt page. Try to
             make <literal>SELECT * FROM
             <replaceable>tbl_name</replaceable></literal> jump over
             corrupt index records and pages, which helps in dumping
@@ -3107,7 +3108,7 @@
 
           <para>
             Prevent the main thread from running. If a crash would occur
-            during the purge operation, this prevents it.
+            during the purge operation, this recovery value prevents it.
           </para>
         </listitem>
 
@@ -3130,7 +3131,7 @@
 
           <para>
             Prevent also insert buffer merge operations. If they would
-            cause a crash, better not do them; do not calculate table
+            cause a crash, do not do them. Do not calculate table
             statistics.
           </para>
         </listitem>
@@ -3162,21 +3163,12 @@
       </itemizedlist>
 
       <para>
-        <emphasis>The database must not otherwise be used with any of
-        these options enabled</emphasis>. As a safety measure,
-        <literal>InnoDB</literal> prevents users from performing
-        <literal>INSERT</literal>, <literal>UPDATE</literal>, or
-        <literal>DELETE</literal> operations when
-        <literal>innodb_force_recovery</literal> is set to a value
-        greater than 0.
-      </para>
-
-      <para>
-        You may <literal>DROP</literal> or <literal>CREATE</literal>
-        tables even if forced recovery is used. If you know that a given
-        table is causing a crash on rollback, you can drop it. You can
-        also use this to stop a runaway rollback caused by a failing
-        mass import or <literal>ALTER TABLE</literal>. You can kill the
+        You can <literal>SELECT</literal> from tables to dump them, or
+        <literal>DROP</literal> or <literal>CREATE</literal> tables even
+        if forced recovery is used. If you know that a given table is
+        causing a crash on rollback, you can drop it. You can also use
+        this to stop a runaway rollback caused by a failing mass import
+        or <literal>ALTER TABLE</literal>. You can kill the
         <command>mysqld</command> process and set
         <literal>innodb_force_recovery</literal> to <literal>3</literal>
         to bring the database up without the rollback, then
@@ -3184,6 +3176,16 @@
         rollback.
       </para>
 
+      <para>
+        <emphasis>The database must not otherwise be used with any
+        non-zero value of
+        <literal>innodb_force_recovery</literal></emphasis>. As a safety
+        measure, <literal>InnoDB</literal> prevents users from
+        performing <literal>INSERT</literal>, <literal>UPDATE</literal>,
+        or <literal>DELETE</literal> operations when
+        <literal>innodb_force_recovery</literal> is greater than 0.
+      </para>
+
     </section>
 
     <section id="innodb-checkpoints">
@@ -3210,26 +3212,26 @@
       </para>
 
       <para>
-        <literal>InnoDB</literal> writes to the log files on a rotating
+        <literal>InnoDB</literal> writes to its log files on a rotating
         basis. All committed modifications that make the database pages
         in the buffer pool different from the images on disk must be
         available in the log files in case <literal>InnoDB</literal> has
         to do a recovery. This means that when <literal>InnoDB</literal>
         starts to reuse a log file, it has to make sure that the
         database page images on disk contain the modifications logged in
-        the log file <literal>InnoDB</literal> is going to reuse. In
-        other words, <literal>InnoDB</literal> must create a checkpoint
-        and this often involves flushing of modified database pages to
-        disk.
+        the log file that <literal>InnoDB</literal> is going to reuse.
+        In other words, <literal>InnoDB</literal> must create a
+        checkpoint and this often involves flushing of modified database
+        pages to disk.
       </para>
 
       <para>
         The preceding description explains why making your log files
         very large may save disk I/O in checkpointing. It often makes
         sense to set the total size of the log files as big as the
-        buffer pool or even bigger. The drawback of big log files is
-        that crash recovery can take longer because there is more logged
-        information to apply to the database.
+        buffer pool or even bigger. The drawback of using large log
+        files is that crash recovery can take longer because there is
+        more logged information to apply to the database.
       </para>
 
     </section>
@@ -3247,8 +3249,8 @@
       have all table and database names in lowercase. A convenient way
       to accomplish this is to add the following line to the
       <literal>[mysqld]</literal> section of your
-      <filename>my.cnf</filename> or <filename>my.ini</filename> before
-      creating any databases or tables:
+      <filename>my.cnf</filename> or <filename>my.ini</filename> file
+      before creating any databases or tables:
     </para>
 
 <programlisting>
@@ -3286,9 +3288,9 @@
     <title>&title-innodb-transaction-model;</title>
 
     <para>
-      In the <literal>InnoDB</literal> transaction model, the goal has
-      been to combine the best properties of a multi-versioning database
-      with traditional two-phase locking. <literal>InnoDB</literal> does
+      In the <literal>InnoDB</literal> transaction model, the goal is to
+      combine the best properties of a multi-versioning database with
+      traditional two-phase locking. <literal>InnoDB</literal> does
       locking on the row level and runs queries as non-locking
       consistent reads by default, in the style of Oracle. The lock
       table in <literal>InnoDB</literal> is stored so space-efficiently
@@ -3325,20 +3327,9 @@
       </itemizedlist>
 
       <para>
-        If a transaction <replaceable>A</replaceable> holds an exclusive
-        (<replaceable>X</replaceable>) lock on tuple
-        <replaceable>t</replaceable>, then a request from some distinct
-        transaction <replaceable>B</replaceable> for a lock of either
-        type on <replaceable>t</replaceable> cannot be granted
-        immediately. Instead, transaction <replaceable>B</replaceable>
-        has to wait for transaction <replaceable>A</replaceable> to
-        release its lock on tuple <replaceable>t</replaceable>.
-      </para>
-
-      <para>
-        If transaction <replaceable>A</replaceable> holds a shared
+        If transaction <literal>T1</literal> holds a shared
         (<replaceable>S</replaceable>) lock on tuple
-        <replaceable>t</replaceable>, then
+        <literal>t</literal>, then
       </para>
 
       <itemizedlist>
@@ -3346,41 +3337,49 @@
         <listitem>
           <para>
             A request from some distinct transaction
-            <replaceable>B</replaceable> for an
-            <replaceable>X</replaceable> lock on
-            <replaceable>t</replaceable> cannot be granted immediately.
+            <literal>T2</literal> for an <replaceable>S</replaceable>
+            lock on <literal>t</literal> can be granted immediately. As
+            a result, both <literal>T1</literal> and
+            <literal>T2</literal> hold an <replaceable>S</replaceable>
+            lock on <literal>t</literal>.
           </para>
         </listitem>
 
         <listitem>
           <para>
             A request from some distinct transaction
-            <replaceable>B</replaceable> for an
-            <replaceable>S</replaceable> lock on
-            <replaceable>t</replaceable> can be granted immediately. As
-            a result, both <replaceable>A</replaceable> and
-            <replaceable>B</replaceable> hold an
-            <replaceable>S</replaceable> lock on
-            <replaceable>t</replaceable>.
+            <literal>T2</literal> for an <replaceable>X</replaceable>
+            lock on <literal>t</literal> cannot be granted immediately.
           </para>
         </listitem>
 
       </itemizedlist>
 
       <para>
+        If a transaction <literal>T1</literal> holds an exclusive
+        (<replaceable>X</replaceable>) lock on tuple
+        <literal>t</literal>, then a request from some distinct
+        transaction <literal>T2</literal> for a lock of either type on
+        <literal>t</literal> cannot be granted immediately. Instead,
+        transaction <literal>T2</literal> has to wait for transaction
+        <literal>T1</literal> to release its lock on tuple
+        <literal>t</literal>.
+      </para>
+
+      <para>
         Additionally, <literal>InnoDB</literal> supports
         <emphasis>multiple granularity locking</emphasis> which allows
         coexistence of record locks and locks on entire tables. To make
         locking at multiple granularity levels practical, additional
-        types of locks, called <emphasis>intention locks</emphasis> are
+        types of locks called <emphasis>intention locks</emphasis> are
         used. Intention locks are table locks in
         <literal>InnoDB</literal>. The idea behind intention locks is
         for a transaction to indicate which type of lock (shared or
         exclusive) it will require later for a row in that table. There
         are two types of intention locks used in
         <literal>InnoDB</literal> (assume that transaction
-        <replaceable>T</replaceable> has requested a lock of the
-        indicated type on table <replaceable>R</replaceable>):
+        <literal>T</literal> has requested a lock of the indicated type
+        on table <literal>R</literal>):
       </para>
 
       <itemizedlist>
@@ -3388,17 +3387,17 @@
         <listitem>
           <para>
             Intention shared (<replaceable>IS</replaceable>):
-            Transaction <replaceable>T</replaceable> intends to set
-            <replaceable>S</replaceable> locks on individual tuples in
-            table <replaceable>T</replaceable>.
+            Transaction <literal>T</literal> intends to set
+            <replaceable>S</replaceable> locks on individual rows in
+            table <literal>R</literal>.
           </para>
         </listitem>
 
         <listitem>
           <para>
             Intention exclusive (<replaceable>IX</replaceable>):
-            Transaction <replaceable>T</replaceable> intends to set
-            <replaceable>X</replaceable> locks on those tuples.
+            Transaction <literal>T</literal> intends to set
+            <replaceable>X</replaceable> locks on those rows.
           </para>
         </listitem>
 
@@ -3438,41 +3437,41 @@
       <informaltable>
         <tgroup cols="5">
           <colspec colwidth="20*"/>
-          <colspec colwidth="10*"/>
-          <colspec colwidth="10*"/>
-          <colspec colwidth="10*"/>
-          <colspec colwidth="10*"/>
+          <colspec colwidth="20*"/>
+          <colspec colwidth="20*"/>
+          <colspec colwidth="20*"/>
+          <colspec colwidth="20*"/>
           <tbody>
             <row>
               <entry/>
-              <entry>X</entry>
-              <entry>IX</entry>
-              <entry>S</entry>
-              <entry>IS</entry>
+              <entry><replaceable>X</replaceable></entry>
+              <entry><replaceable>IX</replaceable></entry>
+              <entry><replaceable>S</replaceable></entry>
+              <entry><replaceable>IS</replaceable></entry>
             </row>
             <row>
-              <entry>X</entry>
+              <entry><replaceable>X</replaceable></entry>
               <entry>Conflict</entry>
               <entry>Conflict</entry>
               <entry>Conflict</entry>
               <entry>Conflict</entry>
             </row>
             <row>
-              <entry>IX</entry>
+              <entry><replaceable>IX</replaceable></entry>
               <entry>Conflict</entry>
               <entry>Compatible</entry>
               <entry>Conflict</entry>
               <entry>Compatible</entry>
             </row>
             <row>
-              <entry>S</entry>
+              <entry><replaceable>S</replaceable></entry>
               <entry>Conflict</entry>
               <entry>Conflict</entry>
               <entry>Compatible</entry>
               <entry>Compatible</entry>
             </row>
             <row>
-              <entry>IS</entry>
+              <entry><replaceable>IS</replaceable></entry>
               <entry>Conflict</entry>
               <entry>Compatible</entry>
               <entry>Compatible</entry>
@@ -4605,7 +4604,7 @@
 
       <listitem>
         <para>
-          Use the <literal>VARCHAR</literal> column type instead of
+          Use the <literal>VARCHAR</literal> data type instead of
           <literal>CHAR</literal> if you are storing variable-length
           strings or if the column may contain many
           <literal>NULL</literal> values. A

Modified: trunk/refman-5.1/ndbcluster.xml
===================================================================
--- trunk/refman-5.1/ndbcluster.xml	2006-01-10 04:12:27 UTC (rev 750)
+++ trunk/refman-5.1/ndbcluster.xml	2006-01-10 05:55:56 UTC (rev 751)
@@ -11905,13 +11905,13 @@
 
       <listitem>
         <para>
-          <emphasis>What column types are supported by MySQL
+          <emphasis>What data types are supported by MySQL
           Cluster?</emphasis>
         </para>
 
         <para>
-          MySQL Cluster supports all of the usual MySQL column types,
-          with the exception of those associated with MySQL's spatial
+          MySQL Cluster supports all of the usual MySQL data types, with
+          the exception of those associated with MySQL's spatial
           extensions. (See <xref linkend="spatial-extensions"/>.) In
           addition, there are some differences with regard to indexes
           when used with <literal>NDB</literal> tables.
@@ -12530,7 +12530,7 @@
           <emphasis role="bold">D</emphasis>ata<emphasis role="bold">b</emphasis>ase,
           and refers to the storage engine used to enable MySQL Cluster.
           The <literal>NDB</literal> storage engine supports all the
-          usual MySQL column types and SQL statements, and is
+          usual MySQL data types and SQL statements, and is
           ACID-compliant. This engine also provides full support for
           transactions (commits and rollbacks).
         </para>

Modified: trunk/refman-5.1/optimization.xml
===================================================================
--- trunk/refman-5.1/optimization.xml	2006-01-10 04:12:27 UTC (rev 750)
+++ trunk/refman-5.1/optimization.xml	2006-01-10 05:55:56 UTC (rev 751)
@@ -502,7 +502,7 @@
 
         <listitem>
           <para>
-            What column types are supported
+            What data types are supported
           </para>
         </listitem>
 
@@ -1743,7 +1743,7 @@
                 <row>
                   <entry><emphasis role="bold">Table</emphasis></entry>
                   <entry><emphasis role="bold">Column</emphasis></entry>
-                  <entry><emphasis role="bold">Column Type</emphasis></entry>
+                  <entry><emphasis role="bold">Data Type</emphasis></entry>
                 </row>
                 <row>
                   <entry><literal>tt</literal></entry>
@@ -6754,7 +6754,7 @@
       </indexterm>
 
       <para>
-        All MySQL column types can be indexed. Use of indexes on the
+        All MySQL data types can be indexed. Use of indexes on the
         relevant columns is the best way to improve the performance of
         <literal>SELECT</literal> operations.
       </para>
@@ -6832,9 +6832,9 @@
       </para>
 
       <para>
-        You can also create indexes on spatial column types. Spatial
-        types are supported only by the <literal>MyISAM</literal>
-        storage engine. Spatial indexes use R-trees.
+        You can also create indexes on spatial data types. Spatial types
+        are supported only by the <literal>MyISAM</literal> storage
+        engine. Spatial indexes use R-trees.
       </para>
 
       <para>
@@ -6865,7 +6865,7 @@
 
       <para>
         MySQL can create indexes on multiple columns. An index may
-        consist of up to 15 columns. For certain column types, you can
+        consist of up to 15 columns. For certain data types, you can
         index a prefix of the column (see <xref linkend="indexes"/>).
       </para>
 
@@ -6968,7 +6968,7 @@
         Most MySQL indexes (<literal>PRIMARY KEY</literal>,
         <literal>UNIQUE</literal>, <literal>INDEX</literal>, and
         <literal>FULLTEXT</literal>) are stored in B-trees. Exceptions
-        are that indexes on spatial column types use R-trees, and that
+        are that indexes on spatial data types use R-trees, and that
         <literal>MEMORY</literal> tables also support hash indexes.
       </para>
 

Modified: trunk/refman-5.1/problems.xml
===================================================================
--- trunk/refman-5.1/problems.xml	2006-01-10 04:12:27 UTC (rev 750)
+++ trunk/refman-5.1/problems.xml	2006-01-10 05:55:56 UTC (rev 751)
@@ -3701,7 +3701,7 @@
       </indexterm>
 
       <para>
-        For some column types, MySQL handles <literal>NULL</literal>
+        For some data types, MySQL handles <literal>NULL</literal>
         values specially. If you insert <literal>NULL</literal> into a
         <literal>TIMESTAMP</literal> column, the current date and time
         is inserted. If you insert <literal>NULL</literal> into an
@@ -3993,7 +3993,7 @@
         Floating-point numbers sometimes cause confusion because they
         are not stored as exact values inside computer architecture.
         What you can see on the screen usually is not the exact value of
-        the number. The column types <literal>FLOAT</literal> and
+        the number. The data types <literal>FLOAT</literal> and
         <literal>DOUBLE</literal> are such. <literal>DECIMAL</literal>
         columns store values with exact precision because they are
         represented as strings.

Modified: trunk/refman-5.1/sql-syntax.xml
===================================================================
--- trunk/refman-5.1/sql-syntax.xml	2006-01-10 04:12:27 UTC (rev 750)
+++ trunk/refman-5.1/sql-syntax.xml	2006-01-10 05:55:56 UTC (rev 751)
@@ -324,7 +324,7 @@
             same syntax for <literal>ADD</literal> and
             <literal>CHANGE</literal> as for <literal>CREATE
             TABLE</literal>. Note that this syntax includes the column
-            name, not just the column type. See
+            name, not just its data type. See
             <xref linkend="create-table"/>.
           </para>
         </listitem>
@@ -377,10 +377,9 @@
 
         <listitem>
           <para>
-            When you change a column type using
-            <literal>CHANGE</literal> or <literal>MODIFY</literal>,
-            MySQL tries to convert existing column values to the new
-            type as well as possible.
+            When you change a data type using <literal>CHANGE</literal>
+            or <literal>MODIFY</literal>, MySQL tries to convert
+            existing column values to the new type as well as possible.
           </para>
         </listitem>
 
@@ -1425,7 +1424,7 @@
       <para>
         <literal>SPATIAL</literal> indexes can include only spatial
         columns, and only in <literal>MyISAM</literal> tables. Spatial
-        column types are described in
+        data types are described in
         <xref linkend="spatial-extensions"/>.
       </para>
 
@@ -1689,7 +1688,7 @@
       <para>
         For general information on the properties of the various column
         types, see <xref linkend="data-types"/>. For information about
-        spatial column types, see <xref linkend="spatial-extensions"/>.
+        spatial data types, see <xref linkend="spatial-extensions"/>.
       </para>
 
       <itemizedlist>
@@ -2212,7 +2211,7 @@
         <listitem>
           <para>
             You can create <literal>SPATIAL</literal> indexes on spatial
-            column types. Spatial types are supported only for
+            data types. Spatial types are supported only for
             <literal>MyISAM</literal> tables and indexed columns must be
             declared as <literal>NOT NULL</literal>. See
             <xref linkend="spatial-extensions"/>.
@@ -3329,7 +3328,7 @@
 </programlisting>
 
       <para>
-        Some conversion of column types might occur. For example, the
+        Some conversion of data types might occur. For example, the
         <literal>AUTO_INCREMENT</literal> attribute is not preserved,
         and <literal>VARCHAR</literal> columns can become
         <literal>CHAR</literal> columns.
@@ -4566,7 +4565,7 @@
             This might involve type conversion if the type of the
             expression does not match the type of the column, and
             conversion of a given value can result in different inserted
-            values depending on the column type. For example, inserting
+            values depending on the data type. For example, inserting
             the string <literal>'1999.0e-2'</literal> into an
             <literal>INT</literal>, <literal>FLOAT</literal>,
             <literal>DECIMAL(10,6)</literal>, or <literal>YEAR</literal>
@@ -4884,8 +4883,8 @@
         <listitem>
           <para>
             Inserting a value into a date or time column that is illegal
-            for the column type. The column is set to the appropriate
-            zero value for the type.
+            for the data type. The column is set to the appropriate zero
+            value for the type.
           </para>
         </listitem>
 
@@ -9926,7 +9925,7 @@
       <para>
         If you update a column that has been declared <literal>NOT
         NULL</literal> by setting to <literal>NULL</literal>, the column
-        is set to the default value appropriate for the column type and
+        is set to the default value appropriate for the data type and
         the warning count is incremented. The default value is
         <literal>0</literal> for numeric types, the empty string
         (<literal>''</literal>) for string types, and the
@@ -10125,9 +10124,9 @@
       </para>
 
       <para>
-        If the column types are different from what you expect them to
-        be based on a <literal>CREATE TABLE</literal> statement, note
-        that MySQL sometimes changes column types. See
+        If the data types are different from what you expect them to be
+        based on a <literal>CREATE TABLE</literal> statement, note that
+        MySQL sometimes changes data types. See
         <xref linkend="silent-column-changes"/>.
       </para>
 
@@ -15011,11 +15010,11 @@
         </para>
 
         <para>
-          If the column types differ from what you expect them to be
-          based on your <literal>CREATE TABLE</literal> statement, note
-          that MySQL sometimes changes column types when you create or
-          alter a table. The conditions for which this occurs are
-          described in <xref linkend="silent-column-changes"/>.
+          If the data types differ from what you expect them to be based
+          on your <literal>CREATE TABLE</literal> statement, note that
+          MySQL sometimes changes data types when you create or alter a
+          table. The conditions for which this occurs are described in
+          <xref linkend="silent-column-changes"/>.
         </para>
 
         <para>
@@ -16275,9 +16274,9 @@
                 <literal>Repair by sorting</literal>, <literal>Repair
                 done</literal>, <literal>Repair with keycache</literal>,
                 <literal>Requesting binlog dump</literal>,
-                <literal>Rolling back</literal>,
-                <literal>Saving state</literal>, <literal>Searching rows
-                for update</literal>, <literal>Sending binlog event to
+                <literal>Rolling back</literal>, <literal>Saving
+                state</literal>, <literal>Searching rows for
+                update</literal>, <literal>Sending binlog event to
                 slave</literal>, <literal>Sending data</literal>,
                 <literal>Sorting for group</literal>, <literal>Sorting
                 for order</literal>, <literal>Sorting index</literal>,

Modified: trunk/refman-5.1/storage-engines.xml
===================================================================
--- trunk/refman-5.1/storage-engines.xml	2006-01-10 04:12:27 UTC (rev 750)
+++ trunk/refman-5.1/storage-engines.xml	2006-01-10 05:55:56 UTC (rev 751)
@@ -1319,8 +1319,7 @@
               <listitem>
                 <para>
                   If a column has only a small set of possible values,
-                  the column type is converted to
-                  <literal>ENUM</literal>.
+                  the data type is converted to <literal>ENUM</literal>.
                 </para>
               </listitem>
 

Modified: trunk/refman-5.1/tutorial.xml
===================================================================
--- trunk/refman-5.1/tutorial.xml	2006-01-10 04:12:27 UTC (rev 750)
+++ trunk/refman-5.1/tutorial.xml	2006-01-10 05:55:56 UTC (rev 751)
@@ -873,9 +873,9 @@
         <literal>VARCHAR</literal> is a good choice for the
         <literal>name</literal>, <literal>owner</literal>, and
         <literal>species</literal> columns because the column values
-        vary in length. The lengths of those columns need not all be the
-        same, and need not be <literal>20</literal>. You can normally
-        pick any length from <literal>1</literal> to
+        vary in length. The lengths in those column definitions need not
+        all be the same, and need not be <literal>20</literal>. You can
+        normally pick any length from <literal>1</literal> to
         <literal>65535</literal>, whatever seems most reasonable to you.
         If you make a poor choice and it turns out later that you need a
         longer field, MySQL provides an <literal>ALTER TABLE</literal>
@@ -935,6 +935,11 @@
         types they have.
       </para>
 
+      <para>
+        For more information about MySQL data types, see
+        <xref linkend="data-types"/>.
+      </para>
+
     </section>
 
     <section id="loading-tables">
@@ -3562,7 +3567,7 @@
 
       <title>&title-example-auto-increment;</title>
 
-      <remark role="help-category" condition="Column Types"/>
+      <remark role="help-category" condition="Data Types"/>
 
       <indexterm>
         <primary>AUTO_INCREMENT</primary>

Modified: trunk/refman-common/news-3.22.xml
===================================================================
--- trunk/refman-common/news-3.22.xml	2006-01-10 04:12:27 UTC (rev 750)
+++ trunk/refman-common/news-3.22.xml	2006-01-10 05:55:56 UTC (rev 751)
@@ -2631,7 +2631,7 @@
       <listitem>
         <para>
           String functions now return <literal>VARCHAR</literal> rather
-          than <literal>CHAR</literal> and the column type is now
+          than <literal>CHAR</literal> and the data type is now
           <literal>VARCHAR</literal> for fields saved as
           <literal>VARCHAR</literal>. This should make the MyODBC driver
           better, but may break some old MySQL clients that don't handle

Modified: trunk/refman-common/news-4.0.xml
===================================================================
--- trunk/refman-common/news-4.0.xml	2006-01-10 04:12:27 UTC (rev 750)
+++ trunk/refman-common/news-4.0.xml	2006-01-10 05:55:56 UTC (rev 751)
@@ -1016,7 +1016,7 @@
         <para>
           Documented problem with using <literal>mysqldump</literal> in
           4.0.x to dump <literal>TIMESTAMP(2)</literal> and
-          <literal>TIMESTAMP(4)</literal> column types. (Bug #6530)
+          <literal>TIMESTAMP(4)</literal> data types. (Bug #6530)
         </para>
       </listitem>
 
@@ -2830,8 +2830,8 @@
       <listitem>
         <para>
           Fixed a crashing bug that occurred due to
-          <literal>BLOB</literal> column type index size being
-          calculated incorrectly in <literal>MIN()</literal> and
+          <literal>BLOB</literal> data type index size being calculated
+          incorrectly in <literal>MIN()</literal> and
           <literal>MAX()</literal> optimizations. (Bug #2189)
         </para>
       </listitem>
@@ -7738,7 +7738,7 @@
         <para>
           Changed behavior of
           <literal>IF(condition,column,NULL)</literal> so that it
-          returns the value of the column type.
+          returns the value in the column's data type.
         </para>
       </listitem>
 

Modified: trunk/refman-common/news-4.1.xml
===================================================================
--- trunk/refman-common/news-4.1.xml	2006-01-10 04:12:27 UTC (rev 750)
+++ trunk/refman-common/news-4.1.xml	2006-01-10 05:55:56 UTC (rev 751)
@@ -1529,7 +1529,7 @@
       <listitem>
         <para>
           Queries that created implicit temporary tables could return
-          incorrect column types for some columns. (Bug #11718)
+          incorrect data types for some columns. (Bug #11718)
         </para>
       </listitem>
 
@@ -4482,7 +4482,7 @@
 
       <listitem>
         <para>
-          The column type for
+          The data type for
           <literal>MAX(<replaceable>datetime_col</replaceable>)</literal>
           was returned as <literal>VARCHAR</literal> rather than
           <literal>DATETIME</literal> if the query included a
@@ -6827,7 +6827,7 @@
           <literal>TIMESTAMP</literal> columns now can store
           <literal>NULL</literal> values. To create such a column, you
           must explicitly specify the <literal>NULL</literal> attribute
-          in the column specification. (Unlike all other column types,
+          in the column specification. (Unlike all other data types,
           <literal>TIMESTAMP</literal> columns are <literal>NOT
           NULL</literal> by default.)
         </para>
@@ -10897,7 +10897,7 @@
 
       <listitem>
         <para>
-          One can specify a column type for a column in <literal>CREATE
+          One can specify a data type for a column in <literal>CREATE
           TABLE ... SELECT</literal> by defining the column in the
           <literal>CREATE</literal> part.
         </para>

Modified: trunk/refman-common/news-5.0.xml
===================================================================
--- trunk/refman-common/news-5.0.xml	2006-01-10 04:12:27 UTC (rev 750)
+++ trunk/refman-common/news-5.0.xml	2006-01-10 05:55:56 UTC (rev 751)
@@ -141,7 +141,7 @@
           <tbody>
             <row>
               <entry><emphasis role="bold">Maximum Length</emphasis></entry>
-              <entry><emphasis role="bold">Column type</emphasis></entry>
+              <entry><emphasis role="bold">Data type</emphasis></entry>
             </row>
             <row>
               <entry>= 0</entry>
@@ -6892,8 +6892,8 @@
 
       <listitem>
         <para>
-          Corrected a problem where an incorrect column type was
-          returned in the result set metadata when using a prepared
+          Corrected a problem where an incorrect data type was returned
+          in the result set metadata when using a prepared
           <literal>SELECT DISTINCT</literal> statement to select from a
           view. (Bug #11111)
         </para>
@@ -8855,7 +8855,7 @@
           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.
+          data type, you should alter the data types of those columns.
           For example:
         </para>
 

Modified: trunk/refman-common/news-connector-j.xml
===================================================================
--- trunk/refman-common/news-connector-j.xml	2006-01-10 04:12:27 UTC (rev 750)
+++ trunk/refman-common/news-connector-j.xml	2006-01-10 05:55:56 UTC (rev 751)
@@ -1458,7 +1458,7 @@
     - Fixed BUG#3557 - UpdatableResultSet not picking up default values
       for moveToInsertRow().
 
-    - Fixed BUG#3570 - inconsistent reporting of column type. The server
+    - Fixed BUG#3570 - inconsistent reporting of data type. The server
       still doesn't return all types for *BLOBs *TEXT correctly, so the
       driver won't return those correctly.
 

Modified: trunk/refman-common/news-connector-net.xml
===================================================================
--- trunk/refman-common/news-connector-net.xml	2006-01-10 04:12:27 UTC (rev 750)
+++ trunk/refman-common/news-connector-net.xml	2006-01-10 05:55:56 UTC (rev 751)
@@ -1283,7 +1283,7 @@
 
       <listitem>
         <para>
-          Removed obsolete column types Long and LongLong
+          Removed obsolete data types Long and LongLong
         </para>
       </listitem>
 

Modified: trunk/refman-common/news-innodb.xml
===================================================================
--- trunk/refman-common/news-innodb.xml	2006-01-10 04:12:27 UTC (rev 750)
+++ trunk/refman-common/news-innodb.xml	2006-01-10 05:55:56 UTC (rev 751)
@@ -1640,7 +1640,7 @@
         <para>
           Fixed a bug: If you dropped a table to which there was a
           <literal>FOREIGN KEY</literal> reference, and later created
-          the same table with non-matching column types,
+          the same table with non-matching data types,
           <literal>InnoDB</literal> could assert in
           <filename>dict0load.c</filename>, in function
           <literal>dict_load_table()</literal>.

Modified: trunk/refman-common/what-is.en.xml
===================================================================
--- trunk/refman-common/what-is.en.xml	2006-01-10 04:12:27 UTC (rev 750)
+++ trunk/refman-common/what-is.en.xml	2006-01-10 05:55:56 UTC (rev 751)
@@ -1050,8 +1050,8 @@
 
       <listitem>
         <para>
-          In MySQL, the <literal>YEAR</literal> column type can store
-          the years <literal>0</literal> and <literal>1901</literal> to
+          In MySQL, the <literal>YEAR</literal> data type can store the
+          years <literal>0</literal> and <literal>1901</literal> to
           <literal>2155</literal> in one byte and display them using two
           or four digits. All two-digit years are considered to be in
           the range <literal>1970</literal> to <literal>2069</literal>,

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