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

Log:
 r5874@frost:  paul | 2006-01-05 12:58:48 -0600
 General revisions.


Modified:
   trunk/
   trunk/refman-4.1/introduction.xml
   trunk/refman-5.0/introduction.xml
   trunk/refman-5.1/introduction.xml
   trunk/refman-common/titles.en.ent


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

Modified: trunk/refman-4.1/introduction.xml
===================================================================
--- trunk/refman-4.1/introduction.xml	2006-01-05 20:42:32 UTC (rev 688)
+++ trunk/refman-4.1/introduction.xml	2006-01-05 20:43:02 UTC (rev 689)
@@ -1961,7 +1961,7 @@
         <title>&title-ansi-diff-subqueries;</title>
 
         <para>
-          MySQL 4.1 supports subqueries and derived tables. A
+          MySQL 4.1 and up supports subqueries and derived tables. A
           <quote>subquery</quote> is a <literal>SELECT</literal>
           statement nested within another statement. A <quote>derived
           table</quote> (an unnamed view) is a subquery in the
@@ -1987,11 +1987,11 @@
         </indexterm>
 
         <para>
-          MySQL Server doesn't support the Sybase SQL extension:
-          <literal>SELECT ... INTO TABLE ...</literal>. Instead, MySQL
-          Server supports the standard SQL syntax <literal>INSERT INTO
-          ... SELECT ...</literal>, which is basically the same thing.
-          See <xref linkend="insert-select"/>.
+          MySQL Server doesn't support the <literal>SELECT &hellip; INTO
+          TABLE</literal> Sybase SQL extension. Instead, MySQL Server
+          supports the <literal>INSERT INTO &hellip; SELECT</literal>
+          standard SQL syntax, which is basically the same thing. See
+          <xref linkend="insert-select"/>. For example:
         </para>
 
 <programlisting>
@@ -2001,8 +2001,9 @@
 </programlisting>
 
         <para>
-          Alternatively, you can use <literal>SELECT INTO OUTFILE
-          ...</literal> or <literal>CREATE TABLE ... SELECT</literal>.
+          Alternatively, you can use <literal>SELECT &hellip; INTO
+          OUTFILE</literal> or <literal>CREATE TABLE &hellip;
+          SELECT</literal>.
         </para>
 
       </section>
@@ -2011,6 +2012,10 @@
 
         <title>&title-ansi-diff-transactions;</title>
 
+        <remark role="todo">
+          Mention NDB.
+        </remark>
+
         <indexterm type="function">
           <primary>COMMIT</primary>
         </indexterm>
@@ -2071,7 +2076,7 @@
         </para>
 
         <para>
-          With MySQL Server supporting both paradigms, you can decide
+          Because MySQL Server supports both paradigms, you can decide
           whether your applications are best served by the speed of
           atomic operations or the use of transactional features. This
           choice can be made on a per-table basis.
@@ -2080,14 +2085,13 @@
         <para>
           As noted, the trade-off for transactional versus
           non-transactional table types lies mostly in performance.
-          Transactional tables have significantly higher memory and
-          diskspace requirements, and more CPU overhead. On the other
-          hand, transactional table types such as
-          <literal>InnoDB</literal> also offer many significant
-          features. MySQL Server's modular design allows the concurrent
-          use of different storage engines to suit different
-          requirements and deliver optimum performance in all
-          situations.
+          Transactional tables have significantly higher memory and disk
+          space requirements, and more CPU overhead. On the other hand,
+          transactional table types such as <literal>InnoDB</literal>
+          also offer many significant features. MySQL Server's modular
+          design allows the concurrent use of different storage engines
+          to suit different requirements and deliver optimum performance
+          in all situations.
         </para>
 
         <para>
@@ -2097,7 +2101,7 @@
           compare with the transactional table types?
         </para>
 
-        <orderedlist>
+        <itemizedlist>
 
           <listitem>
             <para>
@@ -2137,23 +2141,23 @@
 
           <listitem>
             <para>
-              To be safe with MySQL Server, whether or not using
+              To be safe with MySQL Server, whether or not you use
               transactional tables, you only need to have backups and
-              have binary logging turned on. With this you can recover
-              from any situation that you could with any other
+              have binary logging turned on. When that is true, you can
+              recover from any situation that you could with any other
               transactional database system. It is always good to have
               backups, regardless of which database system you use.
             </para>
           </listitem>
 
-        </orderedlist>
+        </itemizedlist>
 
         <para>
           The transactional paradigm has its benefits and its drawbacks.
           Many users and application developers depend on the ease with
           which they can code around problems where an abort appears to
-          be, or is necessary. However, even if you are new to the
-          atomic operations paradigm, or more familiar with
+          be necessary, or is necessary. However, even if you are new to
+          the atomic operations paradigm, or more familiar with
           transactions, do consider the speed benefit that
           non-transactional tables can offer on the order of three to
           five times the speed of the fastest and most optimally tuned
@@ -2171,9 +2175,9 @@
           are allowed, as are inserts by other clients. The newly
           inserted records are not be seen by the client that has the
           read lock until it releases the lock. With <literal>INSERT
-          DELAYED</literal>, you can queue inserts into a local queue,
-          until the locks are released, without having the client wait
-          for the insert to complete. See
+          DELAYED</literal>, you can write inserts that go into a local
+          queue until the locks are released, without having the client
+          wait for the insert to complete. See
           <xref linkend="insert-delayed"/>.
         </para>
 
@@ -2204,7 +2208,7 @@
 
           <listitem>
             <para>
-              To avoid using <literal>ROLLBACK</literal>, you can use
+              To avoid using <literal>ROLLBACK</literal>, you can employ
               the following strategy:
             </para>
 
@@ -2226,7 +2230,7 @@
 
               <listitem>
                 <para>
-                  Update if everything is okay.
+                  Update if the conditions are satisfied.
                 </para>
               </listitem>
 
@@ -2244,7 +2248,7 @@
               transactions with possible rollbacks, although not always.
               The only situation this solution doesn't handle is when
               someone kills the threads in the middle of an update. In
-              this case, all locks are released but some of the updates
+              that case, all locks are released but some of the updates
               may not have been executed.
             </para>
           </listitem>
@@ -2273,12 +2277,12 @@
             </itemizedlist>
 
             <para>
-              For example, when we are doing updates to some customer
-              information, we update only the customer data that has
-              changed and test only that none of the changed data, or
-              data that depends on the changed data, has changed
-              compared to the original row. The test for changed data is
-              done with the <literal>WHERE</literal> clause in the
+              For example, when we are updating customer information, we
+              update only the customer data that has changed and test
+              only that none of the changed data, or data that depends
+              on the changed data, has changed compared to the original
+              row. The test for changed data is done with the
+              <literal>WHERE</literal> clause in the
               <literal>UPDATE</literal> statement. If the record wasn't
               updated, we give the client a message: <quote>Some of the
               data you have changed has been changed by another
@@ -2327,13 +2331,13 @@
               </indexterm>
 
               In many cases, users have wanted <literal>LOCK
-              TABLES</literal> and/or <literal>ROLLBACK</literal> for
-              the purpose of managing unique identifiers. This can be
+              TABLES</literal> or <literal>ROLLBACK</literal> for the
+              purpose of managing unique identifiers. This can be
               handled much more efficiently without locking or rolling
               back by using an <literal>AUTO_INCREMENT</literal> column
               and either the <literal>LAST_INSERT_ID()</literal> SQL
               function or the <literal>mysql_insert_id()</literal> C API
-              function. See <xref linkend="information-functions"/>. See
+              function. See <xref linkend="information-functions"/>, and
               <xref linkend="mysql-insert-id"/>.
             </para>
 
@@ -2351,9 +2355,9 @@
               You can generally code around the need for row-level
               locking. Some situations really do need it, and
               <literal>InnoDB</literal> tables support row-level
-              locking. With <literal>MyISAM</literal> tables, you can
-              use a flag column in the table and do something like the
-              following:
+              locking. Otherwise, with <literal>MyISAM</literal> tables,
+              you can use a flag column in the table and do something
+              like the following:
             </para>
 
 <programlisting>
@@ -2364,14 +2368,10 @@
               MySQL returns <literal>1</literal> for the number of
               affected rows if the row was found and
               <literal>row_flag</literal> wasn't <literal>1</literal> in
-              the original row.
+              the original row. You can think of this as though MySQL
+              Server changed the preceding statement to:
             </para>
 
-            <para>
-              You can think of it as though MySQL Server changed the
-              preceding query to:
-            </para>
-
 <programlisting>
 UPDATE <replaceable>tbl_name</replaceable> SET row_flag=1 WHERE id=ID AND row_flag &lt;&gt; 1;
 </programlisting>

Modified: trunk/refman-5.0/introduction.xml
===================================================================
--- trunk/refman-5.0/introduction.xml	2006-01-05 20:42:32 UTC (rev 688)
+++ trunk/refman-5.0/introduction.xml	2006-01-05 20:43:02 UTC (rev 689)
@@ -1588,7 +1588,7 @@
         <title>&title-ansi-diff-subqueries;</title>
 
         <para>
-          MySQL 4.1 supports subqueries and derived tables. A
+          MySQL 4.1 and up supports subqueries and derived tables. A
           <quote>subquery</quote> is a <literal>SELECT</literal>
           statement nested within another statement. A <quote>derived
           table</quote> (an unnamed view) is a subquery in the
@@ -1614,11 +1614,11 @@
         </indexterm>
 
         <para>
-          MySQL Server doesn't support the Sybase SQL extension:
-          <literal>SELECT ... INTO TABLE ...</literal>. Instead, MySQL
-          Server supports the standard SQL syntax <literal>INSERT INTO
-          ... SELECT ...</literal>, which is basically the same thing.
-          See <xref linkend="insert-select"/>.
+          MySQL Server doesn't support the <literal>SELECT &hellip; INTO
+          TABLE</literal> Sybase SQL extension. Instead, MySQL Server
+          supports the <literal>INSERT INTO &hellip; SELECT</literal>
+          standard SQL syntax, which is basically the same thing. See
+          <xref linkend="insert-select"/>. For example:
         </para>
 
 <programlisting>
@@ -1628,15 +1628,16 @@
 </programlisting>
 
         <para>
-          Alternatively, you can use <literal>SELECT INTO OUTFILE
-          ...</literal> or <literal>CREATE TABLE ... SELECT</literal>.
+          Alternatively, you can use <literal>SELECT &hellip; INTO
+          OUTFILE</literal> or <literal>CREATE TABLE &hellip;
+          SELECT</literal>.
         </para>
 
         <para>
-          From version 5.0, MySQL supports <literal>SELECT ...
-          INTO</literal> with user variables. The same syntax may also
-          be used inside stored procedures using cursors and local
-          variables. See <xref linkend="select-into-statement"/>.
+          As of MySQL 5.0, you can use <literal>SELECT &hellip;
+          INTO</literal> with user-defined variables. The same syntax
+          can also be used inside stored routines using cursors and
+          local variables. See <xref linkend="select-into-statement"/>.
         </para>
 
       </section>
@@ -1645,6 +1646,10 @@
 
         <title>&title-ansi-diff-transactions;</title>
 
+        <remark role="todo">
+          Mention NDB.
+        </remark>
+
         <indexterm type="function">
           <primary>COMMIT</primary>
         </indexterm>
@@ -1704,7 +1709,7 @@
         </para>
 
         <para>
-          With MySQL Server supporting both paradigms, you can decide
+          Because MySQL Server supports both paradigms, you can decide
           whether your applications are best served by the speed of
           atomic operations or the use of transactional features. This
           choice can be made on a per-table basis.
@@ -1713,14 +1718,13 @@
         <para>
           As noted, the trade-off for transactional versus
           non-transactional table types lies mostly in performance.
-          Transactional tables have significantly higher memory and
-          diskspace requirements, and more CPU overhead. On the other
-          hand, transactional table types such as
-          <literal>InnoDB</literal> also offer many significant
-          features. MySQL Server's modular design allows the concurrent
-          use of different storage engines to suit different
-          requirements and deliver optimum performance in all
-          situations.
+          Transactional tables have significantly higher memory and disk
+          space requirements, and more CPU overhead. On the other hand,
+          transactional table types such as <literal>InnoDB</literal>
+          also offer many significant features. MySQL Server's modular
+          design allows the concurrent use of different storage engines
+          to suit different requirements and deliver optimum performance
+          in all situations.
         </para>
 
         <para>
@@ -1730,7 +1734,7 @@
           compare with the transactional table types?
         </para>
 
-        <orderedlist>
+        <itemizedlist>
 
           <listitem>
             <para>
@@ -1770,23 +1774,23 @@
 
           <listitem>
             <para>
-              To be safe with MySQL Server, whether or not using
+              To be safe with MySQL Server, whether or not you use
               transactional tables, you only need to have backups and
-              have binary logging turned on. With this you can recover
-              from any situation that you could with any other
+              have binary logging turned on. When that is true, you can
+              recover from any situation that you could with any other
               transactional database system. It is always good to have
               backups, regardless of which database system you use.
             </para>
           </listitem>
 
-        </orderedlist>
+        </itemizedlist>
 
         <para>
           The transactional paradigm has its benefits and its drawbacks.
           Many users and application developers depend on the ease with
           which they can code around problems where an abort appears to
-          be, or is necessary. However, even if you are new to the
-          atomic operations paradigm, or more familiar with
+          be necessary, or is necessary. However, even if you are new to
+          the atomic operations paradigm, or more familiar with
           transactions, do consider the speed benefit that
           non-transactional tables can offer on the order of three to
           five times the speed of the fastest and most optimally tuned
@@ -1804,9 +1808,9 @@
           are allowed, as are inserts by other clients. The newly
           inserted records are not be seen by the client that has the
           read lock until it releases the lock. With <literal>INSERT
-          DELAYED</literal>, you can queue inserts into a local queue,
-          until the locks are released, without having the client wait
-          for the insert to complete. See
+          DELAYED</literal>, you can write inserts that go into a local
+          queue until the locks are released, without having the client
+          wait for the insert to complete. See
           <xref linkend="insert-delayed"/>.
         </para>
 
@@ -1837,7 +1841,7 @@
 
           <listitem>
             <para>
-              To avoid using <literal>ROLLBACK</literal>, you can use
+              To avoid using <literal>ROLLBACK</literal>, you can employ
               the following strategy:
             </para>
 
@@ -1859,7 +1863,7 @@
 
               <listitem>
                 <para>
-                  Update if everything is okay.
+                  Update if the conditions are satisfied.
                 </para>
               </listitem>
 
@@ -1877,7 +1881,7 @@
               transactions with possible rollbacks, although not always.
               The only situation this solution doesn't handle is when
               someone kills the threads in the middle of an update. In
-              this case, all locks are released but some of the updates
+              that case, all locks are released but some of the updates
               may not have been executed.
             </para>
           </listitem>
@@ -1906,12 +1910,12 @@
             </itemizedlist>
 
             <para>
-              For example, when we are doing updates to some customer
-              information, we update only the customer data that has
-              changed and test only that none of the changed data, or
-              data that depends on the changed data, has changed
-              compared to the original row. The test for changed data is
-              done with the <literal>WHERE</literal> clause in the
+              For example, when we are updating customer information, we
+              update only the customer data that has changed and test
+              only that none of the changed data, or data that depends
+              on the changed data, has changed compared to the original
+              row. The test for changed data is done with the
+              <literal>WHERE</literal> clause in the
               <literal>UPDATE</literal> statement. If the record wasn't
               updated, we give the client a message: <quote>Some of the
               data you have changed has been changed by another
@@ -1960,13 +1964,13 @@
               </indexterm>
 
               In many cases, users have wanted <literal>LOCK
-              TABLES</literal> and/or <literal>ROLLBACK</literal> for
-              the purpose of managing unique identifiers. This can be
+              TABLES</literal> or <literal>ROLLBACK</literal> for the
+              purpose of managing unique identifiers. This can be
               handled much more efficiently without locking or rolling
               back by using an <literal>AUTO_INCREMENT</literal> column
               and either the <literal>LAST_INSERT_ID()</literal> SQL
               function or the <literal>mysql_insert_id()</literal> C API
-              function. See <xref linkend="information-functions"/>. See
+              function. See <xref linkend="information-functions"/>, and
               <xref linkend="mysql-insert-id"/>.
             </para>
 
@@ -1984,9 +1988,9 @@
               You can generally code around the need for row-level
               locking. Some situations really do need it, and
               <literal>InnoDB</literal> tables support row-level
-              locking. With <literal>MyISAM</literal> tables, you can
-              use a flag column in the table and do something like the
-              following:
+              locking. Otherwise, with <literal>MyISAM</literal> tables,
+              you can use a flag column in the table and do something
+              like the following:
             </para>
 
 <programlisting>
@@ -1997,14 +2001,10 @@
               MySQL returns <literal>1</literal> for the number of
               affected rows if the row was found and
               <literal>row_flag</literal> wasn't <literal>1</literal> in
-              the original row.
+              the original row. You can think of this as though MySQL
+              Server changed the preceding statement to:
             </para>
 
-            <para>
-              You can think of it as though MySQL Server changed the
-              preceding query to:
-            </para>
-
 <programlisting>
 UPDATE <replaceable>tbl_name</replaceable> SET row_flag=1 WHERE id=ID AND row_flag &lt;&gt; 1;
 </programlisting>

Modified: trunk/refman-5.1/introduction.xml
===================================================================
--- trunk/refman-5.1/introduction.xml	2006-01-05 20:42:32 UTC (rev 688)
+++ trunk/refman-5.1/introduction.xml	2006-01-05 20:43:02 UTC (rev 689)
@@ -1347,7 +1347,7 @@
         <title>&title-ansi-diff-subqueries;</title>
 
         <para>
-          MySQL 4.1 supports subqueries and derived tables. A
+          MySQL 4.1 and up supports subqueries and derived tables. A
           <quote>subquery</quote> is a <literal>SELECT</literal>
           statement nested within another statement. A <quote>derived
           table</quote> (an unnamed view) is a subquery in the
@@ -1373,11 +1373,11 @@
         </indexterm>
 
         <para>
-          MySQL Server doesn't support the Sybase SQL extension:
-          <literal>SELECT ... INTO TABLE ...</literal>. Instead, MySQL
-          Server supports the standard SQL syntax <literal>INSERT INTO
-          ... SELECT ...</literal>, which is basically the same thing.
-          See <xref linkend="insert-select"/>.
+          MySQL Server doesn't support the <literal>SELECT &hellip; INTO
+          TABLE</literal> Sybase SQL extension. Instead, MySQL Server
+          supports the <literal>INSERT INTO &hellip; SELECT</literal>
+          standard SQL syntax, which is basically the same thing. See
+          <xref linkend="insert-select"/>. For example:
         </para>
 
 <programlisting>
@@ -1387,15 +1387,16 @@
 </programlisting>
 
         <para>
-          Alternatively, you can use <literal>SELECT INTO OUTFILE
-          ...</literal> or <literal>CREATE TABLE ... SELECT</literal>.
+          Alternatively, you can use <literal>SELECT &hellip; INTO
+          OUTFILE</literal> or <literal>CREATE TABLE &hellip;
+          SELECT</literal>.
         </para>
 
         <para>
-          From version 5.0, MySQL supports <literal>SELECT ...
-          INTO</literal> with user variables. The same syntax may also
-          be used inside stored procedures using cursors and local
-          variables. See <xref linkend="select-into-statement"/>.
+          As of MySQL 5.0, you can use <literal>SELECT &hellip;
+          INTO</literal> with user-defined variables. The same syntax
+          can also be used inside stored routines using cursors and
+          local variables. See <xref linkend="select-into-statement"/>.
         </para>
 
       </section>
@@ -1404,6 +1405,10 @@
 
         <title>&title-ansi-diff-transactions;</title>
 
+        <remark role="todo">
+          Mention NDB.
+        </remark>
+
         <indexterm type="function">
           <primary>COMMIT</primary>
         </indexterm>
@@ -1463,7 +1468,7 @@
         </para>
 
         <para>
-          With MySQL Server supporting both paradigms, you can decide
+          Because MySQL Server supports both paradigms, you can decide
           whether your applications are best served by the speed of
           atomic operations or the use of transactional features. This
           choice can be made on a per-table basis.
@@ -1472,14 +1477,13 @@
         <para>
           As noted, the trade-off for transactional versus
           non-transactional table types lies mostly in performance.
-          Transactional tables have significantly higher memory and
-          diskspace requirements, and more CPU overhead. On the other
-          hand, transactional table types such as
-          <literal>InnoDB</literal> also offer many significant
-          features. MySQL Server's modular design allows the concurrent
-          use of different storage engines to suit different
-          requirements and deliver optimum performance in all
-          situations.
+          Transactional tables have significantly higher memory and disk
+          space requirements, and more CPU overhead. On the other hand,
+          transactional table types such as <literal>InnoDB</literal>
+          also offer many significant features. MySQL Server's modular
+          design allows the concurrent use of different storage engines
+          to suit different requirements and deliver optimum performance
+          in all situations.
         </para>
 
         <para>
@@ -1489,7 +1493,7 @@
           compare with the transactional table types?
         </para>
 
-        <orderedlist>
+        <itemizedlist>
 
           <listitem>
             <para>
@@ -1529,23 +1533,23 @@
 
           <listitem>
             <para>
-              To be safe with MySQL Server, whether or not using
+              To be safe with MySQL Server, whether or not you use
               transactional tables, you only need to have backups and
-              have binary logging turned on. With this you can recover
-              from any situation that you could with any other
+              have binary logging turned on. When that is true, you can
+              recover from any situation that you could with any other
               transactional database system. It is always good to have
               backups, regardless of which database system you use.
             </para>
           </listitem>
 
-        </orderedlist>
+        </itemizedlist>
 
         <para>
           The transactional paradigm has its benefits and its drawbacks.
           Many users and application developers depend on the ease with
           which they can code around problems where an abort appears to
-          be, or is necessary. However, even if you are new to the
-          atomic operations paradigm, or more familiar with
+          be necessary, or is necessary. However, even if you are new to
+          the atomic operations paradigm, or more familiar with
           transactions, do consider the speed benefit that
           non-transactional tables can offer on the order of three to
           five times the speed of the fastest and most optimally tuned
@@ -1563,9 +1567,9 @@
           are allowed, as are inserts by other clients. The newly
           inserted records are not be seen by the client that has the
           read lock until it releases the lock. With <literal>INSERT
-          DELAYED</literal>, you can queue inserts into a local queue,
-          until the locks are released, without having the client wait
-          for the insert to complete. See
+          DELAYED</literal>, you can write inserts that go into a local
+          queue until the locks are released, without having the client
+          wait for the insert to complete. See
           <xref linkend="insert-delayed"/>.
         </para>
 
@@ -1596,7 +1600,7 @@
 
           <listitem>
             <para>
-              To avoid using <literal>ROLLBACK</literal>, you can use
+              To avoid using <literal>ROLLBACK</literal>, you can employ
               the following strategy:
             </para>
 
@@ -1618,7 +1622,7 @@
 
               <listitem>
                 <para>
-                  Update if everything is okay.
+                  Update if the conditions are satisfied.
                 </para>
               </listitem>
 
@@ -1636,7 +1640,7 @@
               transactions with possible rollbacks, although not always.
               The only situation this solution doesn't handle is when
               someone kills the threads in the middle of an update. In
-              this case, all locks are released but some of the updates
+              that case, all locks are released but some of the updates
               may not have been executed.
             </para>
           </listitem>
@@ -1665,12 +1669,12 @@
             </itemizedlist>
 
             <para>
-              For example, when we are doing updates to some customer
-              information, we update only the customer data that has
-              changed and test only that none of the changed data, or
-              data that depends on the changed data, has changed
-              compared to the original row. The test for changed data is
-              done with the <literal>WHERE</literal> clause in the
+              For example, when we are updating customer information, we
+              update only the customer data that has changed and test
+              only that none of the changed data, or data that depends
+              on the changed data, has changed compared to the original
+              row. The test for changed data is done with the
+              <literal>WHERE</literal> clause in the
               <literal>UPDATE</literal> statement. If the record wasn't
               updated, we give the client a message: <quote>Some of the
               data you have changed has been changed by another
@@ -1719,13 +1723,13 @@
               </indexterm>
 
               In many cases, users have wanted <literal>LOCK
-              TABLES</literal> and/or <literal>ROLLBACK</literal> for
-              the purpose of managing unique identifiers. This can be
+              TABLES</literal> or <literal>ROLLBACK</literal> for the
+              purpose of managing unique identifiers. This can be
               handled much more efficiently without locking or rolling
               back by using an <literal>AUTO_INCREMENT</literal> column
               and either the <literal>LAST_INSERT_ID()</literal> SQL
               function or the <literal>mysql_insert_id()</literal> C API
-              function. See <xref linkend="information-functions"/>. See
+              function. See <xref linkend="information-functions"/>, and
               <xref linkend="mysql-insert-id"/>.
             </para>
 
@@ -1743,9 +1747,9 @@
               You can generally code around the need for row-level
               locking. Some situations really do need it, and
               <literal>InnoDB</literal> tables support row-level
-              locking. With <literal>MyISAM</literal> tables, you can
-              use a flag column in the table and do something like the
-              following:
+              locking. Otherwise, with <literal>MyISAM</literal> tables,
+              you can use a flag column in the table and do something
+              like the following:
             </para>
 
 <programlisting>
@@ -1756,14 +1760,10 @@
               MySQL returns <literal>1</literal> for the number of
               affected rows if the row was found and
               <literal>row_flag</literal> wasn't <literal>1</literal> in
-              the original row.
+              the original row. You can think of this as though MySQL
+              Server changed the preceding statement to:
             </para>
 
-            <para>
-              You can think of it as though MySQL Server changed the
-              preceding query to:
-            </para>
-
 <programlisting>
 UPDATE <replaceable>tbl_name</replaceable> SET row_flag=1 WHERE id=ID AND row_flag &lt;&gt; 1;
 </programlisting>

Modified: trunk/refman-common/titles.en.ent
===================================================================
--- trunk/refman-common/titles.en.ent	2006-01-05 20:42:32 UTC (rev 688)
+++ trunk/refman-common/titles.en.ent	2006-01-05 20:43:02 UTC (rev 689)
@@ -38,7 +38,7 @@
 <!ENTITY title-ansi-diff-comments "'<literal>--</literal>' as the Start of a Comment">
 <!ENTITY title-ansi-diff-foreign-keys "Foreign Keys">
 <!ENTITY title-ansi-diff-select-into-table "<literal>SELECT INTO TABLE</literal>">
-<!ENTITY title-ansi-diff-subqueries "Subqueries">
+<!ENTITY title-ansi-diff-subqueries "Subquery Support">
 <!ENTITY title-ansi-diff-transactions "Transactions and Atomic Operations">
 <!ENTITY title-ansi-diff-triggers "Stored Procedures and Triggers">
 <!ENTITY title-ansi-diff-views "Views">

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