List:Commits« Previous MessageNext Message »
From:paul Date:January 29 2006 5:00am
Subject:svn commit - mysqldoc@docsrva: r1097 - in trunk: . refman-4.1 refman-5.0 refman-5.1
View as plain text  
Author: paul
Date: 2006-01-29 06:00:39 +0100 (Sun, 29 Jan 2006)
New Revision: 1097

Log:
 r6845@frost:  paul | 2006-01-28 21:27:38 -0600
 General revisions.


Modified:
   trunk/
   trunk/refman-4.1/client-utility-programs.xml
   trunk/refman-4.1/database-administration.xml
   trunk/refman-4.1/functions.xml
   trunk/refman-4.1/storage-engines.xml
   trunk/refman-5.0/client-utility-programs.xml
   trunk/refman-5.0/database-administration.xml
   trunk/refman-5.0/functions.xml
   trunk/refman-5.0/storage-engines.xml
   trunk/refman-5.0/triggers.xml
   trunk/refman-5.1/client-utility-programs.xml
   trunk/refman-5.1/custom-engine.xml
   trunk/refman-5.1/database-administration.xml
   trunk/refman-5.1/functions.xml
   trunk/refman-5.1/partitioning.xml
   trunk/refman-5.1/storage-engines.xml
   trunk/refman-5.1/triggers.xml


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

Modified: trunk/refman-4.1/client-utility-programs.xml
===================================================================
--- trunk/refman-4.1/client-utility-programs.xml	2006-01-29 05:00:13 UTC (rev 1096)
+++ trunk/refman-4.1/client-utility-programs.xml	2006-01-29 05:00:39 UTC (rev 1097)
@@ -6200,7 +6200,7 @@
           you to perform point-in-time recovery using the
           <option>--stop-datetime</option> option (to be able to say,
           for example, <quote>roll forward my databases to how they were
-          today at 10:30 AM</quote>).
+          today at 10:30 a.m.</quote>).
         </para>
 
         <para>

Modified: trunk/refman-4.1/database-administration.xml
===================================================================
--- trunk/refman-4.1/database-administration.xml	2006-01-29 05:00:13 UTC (rev 1096)
+++ trunk/refman-4.1/database-administration.xml	2006-01-29 05:00:39 UTC (rev 1097)
@@ -16619,7 +16619,7 @@
         </para>
 
         <para>
-          Assume that we make a backup on Sunday at 1 PM, when load is
+          Assume that we make a backup on Sunday at 1 p.m., when load is
           low. The following command makes a full backup of all our
           <literal>InnoDB</literal> tables in all databases:
         </para>
@@ -16759,18 +16759,18 @@
         </itemizedlist>
 
         <para>
-          On Monday at 1 PM, we can create an incremental backup by
+          On Monday at 1 p.m., we can create an incremental backup by
           flushing the logs to begin a new binary log file. For example,
           executing a <command>mysqladmin flush-logs</command> command
           creates <filename>gbichot2-bin.000008</filename>. All changes
-          between the Sunday 1 PM full backup and Monday 1 PM will be in
-          the <filename>gbichot2-bin.000007</filename> file. This
+          between the Sunday 1 p.m. full backup and Monday 1 p.m. will
+          be in the <filename>gbichot2-bin.000007</filename> file. This
           incremental backup is important, so it's a good idea to copy
           it to a safe place. (For example, back it up on tape or DVD,
-          or copy it to another machine.) On Tuesday at 1 PM, execute
+          or copy it to another machine.) On Tuesday at 1 p.m., execute
           another <command>mysqladmin flush-logs</command> command. All
-          changes between Monday 1 PM and Tuesday 1 PM will be in the
-          <filename>gbichot2-bin.000008</filename> file (which also
+          changes between Monday 1 p.m. and Tuesday 1 p.m. will be in
+          the <filename>gbichot2-bin.000008</filename> file (which also
           should be copied somewhere safe).
         </para>
 
@@ -16805,10 +16805,10 @@
 
         <para>
           Now, suppose that we have a catastrophic crash on Wednesday at
-          8 AM that requires recovery from backups. To recover, first we
-          restore the last full backup we have (the one from Sunday 1
-          PM). The full backup file is just a set of SQL statements, so
-          restoring it is very easy:
+          8 a.m. that requires recovery from backups. To recover, first
+          we restore the last full backup we have (the one from Sunday 1
+          p.m.). The full backup file is just a set of SQL statements,
+          so restoring it is very easy:
         </para>
 
 <programlisting>
@@ -16817,8 +16817,8 @@
 
         <para>
           At this point, the data is restored to its state as of Sunday
-          1 PM. To restore the changes made since then, we must use the
-          incremental backups; that is, the
+          1 p.m.. To restore the changes made since then, we must use
+          the incremental backups; that is, the
           <filename>gbichot2-bin.000007</filename> and
           <filename>gbichot2-bin.000008</filename> binary log files.
           Fetch them if necessary from where they were backed up, and
@@ -16831,8 +16831,8 @@
 
         <para>
           We now have recovered the data to its state as of Tuesday 1
-          PM, but still are missing the changes from that date to the
-          date of the crash. To not miss them, we would have needed to
+          p.m., but still are missing the changes from that date to the
+          date of the crash. To not lose them, we would have needed to
           have the MySQL server store its MySQL binary logs into a safe
           location (RAID disks, SAN, ...) different from the place where
           it stores its data files, so that these logs were not in the
@@ -16841,9 +16841,11 @@
           a different physical device than the one on which the data
           directory resides. That way, the logs are not lost even if the
           device containing the directory is.) If we had done this, we
-          would have the <filename>gbichot2-bin.000009</filename> at
-          hand, and we could apply it to restore the most recent data
-          changes with no loss of data up to the moment of the crash.
+          would have the <filename>gbichot2-bin.000009</filename> file
+          at hand, and we could apply it using
+          <command>mysqlbinlog</command> and <command>mysql</command> to
+          restore the most recent data changes with no loss up to the
+          moment of the crash.
         </para>
 
       </section>
@@ -16910,44 +16912,43 @@
       </indexterm>
 
       <para>
-        If a MySQL server has the binary log enabled, you can use the
+        If a MySQL server has binary logging enabled, you can use the
         <command>mysqlbinlog</command> utility to recover data starting
         from a specified point in time (for example, since your last
         backup) until the present or another specified point in time.
-        For information on enabling the binary log, see
-        <xref linkend="binary-log"/>. For more information on the
+        For information on enabling the binary log and using
         <command>mysqlbinlog</command>, see
-        <xref linkend="mysqlbinlog"/>.
+        <xref linkend="binary-log"/>, and <xref linkend="mysqlbinlog"/>.
       </para>
 
       <para>
-        To be able to restore data from a binary log, you will need to
-        know the path and name of the current binary log file. The path
-        can typically be found in the options file (that is,
+        To restore data from a binary log, you will need to know the
+        path and name of the current binary log file. The path can
+        typically be found in the option file (that is,
         <filename>my.cnf</filename> or <filename>my.ini</filename>,
-        depending on your system). If it is not contained in the options
-        file, it may be given as an option at the command-line when the
-        server is started. The option for enabling binary logging is
-        <option>--log-bin</option>. To determine the name of the current
-        binary log file, enter the following statement in MySQL:
+        depending on your system). If the path is not contained in the
+        option file, it may be given as an option at the command-line
+        when the server is started. The option for enabling binary
+        logging is <option>--log-bin</option>. To determine the name of
+        the current binary log file, issue the following statement:
       </para>
 
 <programlisting>
-SHOW BINLOG EVENTS \G
+mysql&gt; <userinput>SHOW BINLOG EVENTS \G</userinput>
 </programlisting>
 
       <para>
-        If you prefer, you could enter the following from the command
-        line instead:
+        If you prefer, you could execute the following command from the
+        command line instead:
       </para>
 
 <programlisting>
-mysql --user=<replaceable>root</replaceable> -p<replaceable>my_pwd</replaceable> -E -e 'SHOW BINLOG EVENTS'
+shell&gt; <userinput>mysql --user=root -p -E -e "SHOW BINLOG EVENTS"</userinput>
 </programlisting>
 
       <para>
-        Replace the password <replaceable>my_pwd</replaceable> with the
-        <replaceable>root</replaceable> password for your server.
+        Enter the <literal>root</literal> password for your server when
+        <command>mysql</command> prompts you for it.
       </para>
 
       <section id="point-in-time-recovery-times">
@@ -16955,47 +16956,44 @@
         <title>&title-point-in-time-recovery-times;</title>
 
         <para>
-          As of version 4.1.4 of MySQL, the
-          <option>--start-date</option> and the
-          <option>--stop-date</option> options are available for
-          <command>mysqlbinlog</command> to specify the start and end
-          times in the <literal>DATETIME</literal> format. As an
-          example, suppose that exactly at 10:00:00 a.m. today
-          (<quote>today</quote> being April 20, 2005) an SQL statement
-          was executed which deleted a large table. To restore the table
+          To indicate the start and end times for recovery, specify the
+          <option>--start-date</option> and <option>--stop-date</option>
+          options for <command>mysqlbinlog</command>, in
+          <literal>DATETIME</literal> format. As an example, suppose
+          that exactly at 10:00 a.m. on April 20, 2005 an SQL statement
+          was executed that deleted a large table. To restore the table
           and data, you could restore the previous night's backup, and
-          then enter the following:
+          then execute the following command:
         </para>
 
 <programlisting>
-mysqlbinlog --stop-date="2005-04-20 9:59:59" /var/log/mysql/bin.123456 \
-     | mysql -u <replaceable>root</replaceable> -p<replaceable>mypwd</replaceable>
+shell&gt; <userinput>mysqlbinlog --stop-date="2005-04-20 9:59:59" \</userinput>
+         <userinput>/var/log/mysql/bin.123456 | mysql -u root -p</userinput>
 </programlisting>
 
         <para>
-          This will recover all of the data up until the date and time
-          given as a <literal>DATETIME</literal> format for the
-          <option>--stop-date</option> option. If you did not detect the
-          erroneous SQL statement that was entered until hours later,
-          you will probably want to recover the activity that occurred
-          afterwards, as well. Based on this, you could run the
+          This command recovers all of the data up until the date and
+          time given by the <option>--stop-date</option> option. If you
+          did not detect the erroneous SQL statement that was entered
+          until hours later, you will probably also want to recover the
+          activity that occurred afterward. Based on this, you could run
           <command>mysqlbinlog</command> again with a start date and
-          time like so:
+          time, like so:
         </para>
 
 <programlisting>
-mysqlbinlog --start-date="2005-04-20 10:01:00" /var/log/mysql/bin.123456 \
-     | mysql -u <replaceable>root</replaceable> -p<replaceable>mypwd</replaceable> \
+shell&gt; <userinput>mysqlbinlog --start-date="2005-04-20 10:01:00" \</userinput>
+         <userinput>/var/log/mysql/bin.123456 | mysql -u root -p</userinput>
 </programlisting>
 
         <para>
-          In this line, the SQL statements logged from 10:01 a.m. will
-          be run. The combination of executing of the previous night's
-          dump file and the two lines of the
-          <command>mysqlbinlog</command> will restore everything up
+          In this command, the SQL statements logged from 10:01 a.m. on
+          will be re-executed. The combination of restoring of the
+          previous night's dump file and the two
+          <command>mysqlbinlog</command> commands restores everything up
           until one second before 10:00 a.m. and everything from 10:01
           a.m. on. You should examine the log to be sure of the exact
-          times. The next section explains how this might be done.
+          times. The next section explains how to do this.
         </para>
 
       </section>
@@ -17005,52 +17003,52 @@
         <title>&title-point-in-time-recovery-positions;</title>
 
         <para>
-          Instead of specifying dates and times, the options
+          Instead of specifying dates and times, the
           <option>--start-position</option> and
-          <option>--stop-position</option> for
-          <command>mysqlbinlog</command> could be used for specifying
-          log positions. They work the same as the start and stop date
+          <option>--stop-position</option> options for
+          <command>mysqlbinlog</command> can be used for specifying log
+          positions. They work the same as the start and stop date
           options, except that position numbers from the log are given.
           Using log positions may a be more accurate recovery method,
           especially if many transactions occurred around the same time
           as a damaging SQL statement. To determine the position
           numbers, you could run <command>mysqlbinlog</command> for a
-          range of times around when the unwanted transaction was
+          range of times near the time when the unwanted transaction was
           executed, but redirect the results to a text file for
           examination. This can be done like so:
         </para>
 
 <programlisting>
-mysqlbinlog --start-date="2005-04-20 9:55:00" \
-      --stop-date="2005-04-20 10:05:00" \
-      /var/log/mysql/bin.123456 &gt; /tmp/mysql_restore.sql
+shell&gt; <userinput>mysqlbinlog --start-date="2005-04-20 9:55:00" \</userinput>
+         <userinput>--stop-date="2005-04-20 10:05:00" \</userinput>
+         <userinput>/var/log/mysql/bin.123456 &gt; /tmp/mysql_restore.sql</userinput>
 </programlisting>
 
         <para>
-          This will create a small text file in the
-          <filename>/tmp</filename> directory which will show the SQL
-          statements around the time the deleterious SQL statement was
-          executed. You would then open this file with a text editor and
-          look for the statement that you do not want to repeat. Once
-          the position numbers in the binary log are determined for
-          stopping and resuming the recovery, make note of them.
-          Positions are labeled with <literal>log_pos</literal> followed
-          by a number. After restoring the previous backup file, using
-          the position numbers, you would then enter something like the
-          following from the command line:
+          This command creates a small text file in the
+          <filename>/tmp</filename> directory that contains the SQL
+          statements around the time that the deleterious SQL statement
+          was executed. Open this file with a text editor and look for
+          the statement that you don't want to repeat. Determine the
+          positions in the binary log for stopping and resuming the
+          recovery and make note of them. Positions are labeled as
+          <literal>log_pos</literal> followed by a number. After
+          restoring the previous backup file, use the position numbers
+          to process the binary log file. For example, you would use
+          commands something like these:
         </para>
 
 <programlisting>
-mysqlbinlog --stop-position="368312" /var/log/mysql/bin.123456 \
-    | mysql -u <replaceable>root</replaceable> -p<replaceable>mypwd</replaceable> 
+shell&gt; <userinput>mysqlbinlog --stop-position="368312" /var/log/mysql/bin.123456 \</userinput>
+         <userinput>| mysql -u root -p</userinput>
 
-mysqlbinlog --start-position="368315" /var/log/mysql/bin.123456 \
-    | mysql -u <replaceable>root</replaceable> -p<replaceable>mypwd</replaceable> \ 
+shell&gt; <userinput>mysqlbinlog --start-position="368315" /var/log/mysql/bin.123456 \</userinput>
+         <userinput>| mysql -u root -p</userinput>
 </programlisting>
 
         <para>
-          The first line above will recover all of the transactions up
-          until the stop position given. The next line will recover all
+          The first command recovers all the transactions up until the
+          stop position given. The second command recovers all
           transactions from the starting position given until the end of
           the binary log. Because the output of
           <command>mysqlbinlog</command> includes <literal>SET
@@ -17690,7 +17688,7 @@
           <listitem>
             <para>
               Copy the old data file back onto the newly created data
-              file. (do not just move the old file back onto the new
+              file. (Don't just move the old file back onto the new
               file; you want to retain a copy in case something goes
               wrong.)
             </para>
@@ -20020,10 +20018,10 @@
       </para>
 
       <para>
-        To be able to know which different binary log files have been
-        used, <command>mysqld</command> also creates a binary log index
-        file that contains the name of all used binary log files. By
-        default this has the same name as the binary log file, with the
+        To keep track of which binary log files have been used,
+        <command>mysqld</command> also creates a binary log index file
+        that contains the names of all used binary log files. By default
+        this has the same name as the binary log file, with the
         extension <literal>'.index'</literal>. You can change the name
         of the binary log index file with the
         <option>--log-bin-index[=<replaceable>file_name</replaceable>]</option>

Modified: trunk/refman-4.1/functions.xml
===================================================================
--- trunk/refman-4.1/functions.xml	2006-01-29 05:00:13 UTC (rev 1096)
+++ trunk/refman-4.1/functions.xml	2006-01-29 05:00:39 UTC (rev 1097)
@@ -704,8 +704,8 @@
               <secondary>with ODBC</secondary>
             </indexterm>
 
-            To be able to work well with ODBC programs, MySQL supports
-            the following extra features when using <literal>IS
+            To work well with ODBC programs, MySQL supports the
+            following extra features when using <literal>IS
             NULL</literal>:
           </para>
 
@@ -9062,7 +9062,7 @@
           <literal>ALTER TABLE</literal> or <literal>CREATE
           INDEX</literal>. For large datasets, it is much faster to load
           your data into a table that has no <literal>FULLTEXT</literal>
-          index and then create the index afterwards, than to load data
+          index and then create the index after that, than to load data
           into a table that has an existing <literal>FULLTEXT</literal>
           index.
         </para>

Modified: trunk/refman-4.1/storage-engines.xml
===================================================================
--- trunk/refman-4.1/storage-engines.xml	2006-01-29 05:00:13 UTC (rev 1096)
+++ trunk/refman-4.1/storage-engines.xml	2006-01-29 05:00:39 UTC (rev 1097)
@@ -3050,12 +3050,11 @@
 
         <listitem>
           <para>
-            To be able to roll back transactions, the
-            <literal>BDB</literal> storage engine maintains log files.
-            For maximum performance, you can use the
-            <option>--bdb-logdir</option> option to place the
-            <literal>BDB</literal> logs on a different disk than the one
-            where your databases are located.
+            To support transaction rollback, the <literal>BDB</literal>
+            storage engine maintains log files. For maximum performance,
+            you can use the <option>--bdb-logdir</option> option to
+            place the <literal>BDB</literal> logs on a different disk
+            than the one where your databases are located.
           </para>
         </listitem>
 

Modified: trunk/refman-5.0/client-utility-programs.xml
===================================================================
--- trunk/refman-5.0/client-utility-programs.xml	2006-01-29 05:00:13 UTC (rev 1096)
+++ trunk/refman-5.0/client-utility-programs.xml	2006-01-29 05:00:39 UTC (rev 1097)
@@ -6088,7 +6088,7 @@
           you to perform point-in-time recovery using the
           <option>--stop-datetime</option> option (to be able to say,
           for example, <quote>roll forward my databases to how they were
-          today at 10:30 AM</quote>).
+          today at 10:30 a.m.</quote>).
         </para>
 
         <para>

Modified: trunk/refman-5.0/database-administration.xml
===================================================================
--- trunk/refman-5.0/database-administration.xml	2006-01-29 05:00:13 UTC (rev 1096)
+++ trunk/refman-5.0/database-administration.xml	2006-01-29 05:00:39 UTC (rev 1097)
@@ -18868,7 +18868,7 @@
         </para>
 
         <para>
-          Assume that we make a backup on Sunday at 1 PM, when load is
+          Assume that we make a backup on Sunday at 1 p.m., when load is
           low. The following command makes a full backup of all our
           <literal>InnoDB</literal> tables in all databases:
         </para>
@@ -19007,18 +19007,18 @@
         </itemizedlist>
 
         <para>
-          On Monday at 1 PM, we can create an incremental backup by
+          On Monday at 1 p.m., we can create an incremental backup by
           flushing the logs to begin a new binary log file. For example,
           executing a <command>mysqladmin flush-logs</command> command
           creates <filename>gbichot2-bin.000008</filename>. All changes
-          between the Sunday 1 PM full backup and Monday 1 PM will be in
-          the <filename>gbichot2-bin.000007</filename> file. This
+          between the Sunday 1 p.m. full backup and Monday 1 p.m. will
+          be in the <filename>gbichot2-bin.000007</filename> file. This
           incremental backup is important, so it's a good idea to copy
           it to a safe place. (For example, back it up on tape or DVD,
-          or copy it to another machine.) On Tuesday at 1 PM, execute
+          or copy it to another machine.) On Tuesday at 1 p.m., execute
           another <command>mysqladmin flush-logs</command> command. All
-          changes between Monday 1 PM and Tuesday 1 PM will be in the
-          <filename>gbichot2-bin.000008</filename> file (which also
+          changes between Monday 1 p.m. and Tuesday 1 p.m. will be in
+          the <filename>gbichot2-bin.000008</filename> file (which also
           should be copied somewhere safe).
         </para>
 
@@ -19053,10 +19053,10 @@
 
         <para>
           Now, suppose that we have a catastrophic crash on Wednesday at
-          8 AM that requires recovery from backups. To recover, first we
-          restore the last full backup we have (the one from Sunday 1
-          PM). The full backup file is just a set of SQL statements, so
-          restoring it is very easy:
+          8 a.m. that requires recovery from backups. To recover, first
+          we restore the last full backup we have (the one from Sunday 1
+          p.m.). The full backup file is just a set of SQL statements,
+          so restoring it is very easy:
         </para>
 
 <programlisting>
@@ -19065,8 +19065,8 @@
 
         <para>
           At this point, the data is restored to its state as of Sunday
-          1 PM. To restore the changes made since then, we must use the
-          incremental backups; that is, the
+          1 p.m.. To restore the changes made since then, we must use
+          the incremental backups; that is, the
           <filename>gbichot2-bin.000007</filename> and
           <filename>gbichot2-bin.000008</filename> binary log files.
           Fetch them if necessary from where they were backed up, and
@@ -19079,8 +19079,8 @@
 
         <para>
           We now have recovered the data to its state as of Tuesday 1
-          PM, but still are missing the changes from that date to the
-          date of the crash. To not miss them, we would have needed to
+          p.m., but still are missing the changes from that date to the
+          date of the crash. To not lose them, we would have needed to
           have the MySQL server store its MySQL binary logs into a safe
           location (RAID disks, SAN, ...) different from the place where
           it stores its data files, so that these logs were not in the
@@ -19089,9 +19089,11 @@
           a different physical device than the one on which the data
           directory resides. That way, the logs are not lost even if the
           device containing the directory is.) If we had done this, we
-          would have the <filename>gbichot2-bin.000009</filename> at
-          hand, and we could apply it to restore the most recent data
-          changes with no loss how it was at the moment of the crash.
+          would have the <filename>gbichot2-bin.000009</filename> file
+          at hand, and we could apply it using
+          <command>mysqlbinlog</command> and <command>mysql</command> to
+          restore the most recent data changes with no loss up to the
+          moment of the crash.
         </para>
 
       </section>
@@ -19158,44 +19160,43 @@
       </indexterm>
 
       <para>
-        If a MySQL server has the binary log enabled, you can use the
+        If a MySQL server has binary logging enabled, you can use the
         <command>mysqlbinlog</command> utility to recover data starting
         from a specified point in time (for example, since your last
         backup) until the present or another specified point in time.
-        For information on enabling the binary log, see
-        <xref linkend="binary-log"/>. For more information on the
+        For information on enabling the binary log and using
         <command>mysqlbinlog</command>, see
-        <xref linkend="mysqlbinlog"/>.
+        <xref linkend="binary-log"/>, and <xref linkend="mysqlbinlog"/>.
       </para>
 
       <para>
-        To be able to restore data from a binary log, you will need to
-        know the path and name of the current binary log file. The path
-        can typically be found in the options file (that is,
+        To restore data from a binary log, you will need to know the
+        path and name of the current binary log file. The path can
+        typically be found in the option file (that is,
         <filename>my.cnf</filename> or <filename>my.ini</filename>,
-        depending on your system). If it's not contained in the options
-        file, it may be given as an option at the command-line when the
-        server is started. The option for enabling binary logging is
-        <option>--log-bin</option>. To determine the name of the current
-        binary log file, enter the following statement in MySQL:
+        depending on your system). If the path is not contained in the
+        option file, it may be given as an option at the command-line
+        when the server is started. The option for enabling binary
+        logging is <option>--log-bin</option>. To determine the name of
+        the current binary log file, issue the following statement:
       </para>
 
 <programlisting>
-SHOW BINLOG EVENTS \G
+mysql&gt; <userinput>SHOW BINLOG EVENTS \G</userinput>
 </programlisting>
 
       <para>
-        If you prefer, you could enter the following from the command
-        line instead:
+        If you prefer, you could execute the following command from the
+        command line instead:
       </para>
 
 <programlisting>
-mysql --user=<replaceable>root</replaceable> -p<replaceable>my_pwd</replaceable> -E -e 'SHOW BINLOG EVENTS'
+shell&gt; <userinput>mysql --user=root -p -E -e "SHOW BINLOG EVENTS"</userinput>
 </programlisting>
 
       <para>
-        Replace the password <replaceable>my_pwd</replaceable> with the
-        <replaceable>root</replaceable> password for your server.
+        Enter the <literal>root</literal> password for your server when
+        <command>mysql</command> prompts you for it.
       </para>
 
       <section id="point-in-time-recovery-times">
@@ -19203,46 +19204,44 @@
         <title>&title-point-in-time-recovery-times;</title>
 
         <para>
-          As of version 4.1.4 of MySQL, the
-          <option>--start-date</option> and the
-          <option>--stop-date</option> options are available for
-          <command>mysqlbinlog</command> to specify the start and end
-          times in the <literal>DATETIME</literal> format. As an
-          example, suppose that exactly at 10:00 a.m. today (today being
-          April 20, 2005) an SQL statement was executed which deleted a
-          large table. To restore the table and data, you could restore
-          the previous night's backup, and then enter the following:
+          To indicate the start and end times for recovery, specify the
+          <option>--start-date</option> and <option>--stop-date</option>
+          options for <command>mysqlbinlog</command>, in
+          <literal>DATETIME</literal> format. As an example, suppose
+          that exactly at 10:00 a.m. on April 20, 2005 an SQL statement
+          was executed that deleted a large table. To restore the table
+          and data, you could restore the previous night's backup, and
+          then execute the following command:
         </para>
 
 <programlisting>
-mysqlbinlog --stop-date="2005-04-20 9:59:59" /var/log/mysql/bin.123456 \
-     | mysql -u <replaceable>root</replaceable> -p<replaceable>mypwd</replaceable>
+shell&gt; <userinput>mysqlbinlog --stop-date="2005-04-20 9:59:59" \</userinput>
+         <userinput>/var/log/mysql/bin.123456 | mysql -u root -p</userinput>
 </programlisting>
 
         <para>
-          This will recover all of the data up until the date and time
-          given as a <literal>DATETIME</literal> format for the
-          <option>--stop-date</option> option. If you did not detect the
-          erroneous SQL statement that was entered until hours later,
-          you will probably want to recover the activity that occurred
-          afterwards, as well. Based on this, you could run the
+          This command recovers all of the data up until the date and
+          time given by the <option>--stop-date</option> option. If you
+          did not detect the erroneous SQL statement that was entered
+          until hours later, you will probably also want to recover the
+          activity that occurred afterward. Based on this, you could run
           <command>mysqlbinlog</command> again with a start date and
-          time like so:
+          time, like so:
         </para>
 
 <programlisting>
-mysqlbinlog --start-date="2005-04-20 10:01:00" /var/log/mysql/bin.123456 \
-     | mysql -u <replaceable>root</replaceable> -p<replaceable>mypwd</replaceable> \
+shell&gt; <userinput>mysqlbinlog --start-date="2005-04-20 10:01:00" \</userinput>
+         <userinput>/var/log/mysql/bin.123456 | mysql -u root -p</userinput>
 </programlisting>
 
         <para>
-          In this line, the SQL statements logged from 10:01 a.m. will
-          be run. The combination of executing of the previous night's
-          dump file and the two lines of the
-          <command>mysqlbinlog</command> will restore everything up
+          In this command, the SQL statements logged from 10:01 a.m. on
+          will be re-executed. The combination of restoring of the
+          previous night's dump file and the two
+          <command>mysqlbinlog</command> commands restores everything up
           until one second before 10:00 a.m. and everything from 10:01
           a.m. on. You should examine the log to be sure of the exact
-          times. The next section explains how this might be done.
+          times. The next section explains how to do this.
         </para>
 
       </section>
@@ -19252,52 +19251,52 @@
         <title>&title-point-in-time-recovery-positions;</title>
 
         <para>
-          Instead of specifying dates and times, the options
+          Instead of specifying dates and times, the
           <option>--start-position</option> and
-          <option>--stop-position</option> for
-          <command>mysqlbinlog</command> could be used for specifying
-          log positions. They work the same as the start and stop date
+          <option>--stop-position</option> options for
+          <command>mysqlbinlog</command> can be used for specifying log
+          positions. They work the same as the start and stop date
           options, except that position numbers from the log are given.
           Using log positions may a be more accurate recovery method,
           especially if many transactions occurred around the same time
           as a damaging SQL statement. To determine the position
           numbers, you could run <command>mysqlbinlog</command> for a
-          range of times around when the unwanted transaction was
+          range of times near the time when the unwanted transaction was
           executed, but redirect the results to a text file for
           examination. This can be done like so:
         </para>
 
 <programlisting>
-mysqlbinlog --start-date="2005-04-20 9:55:00" \
-      --stop-date="2005-04-20 10:05:00" \
-      /var/log/mysql/bin.123456 &gt; /tmp/mysql_restore.sql
+shell&gt; <userinput>mysqlbinlog --start-date="2005-04-20 9:55:00" \</userinput>
+         <userinput>--stop-date="2005-04-20 10:05:00" \</userinput>
+         <userinput>/var/log/mysql/bin.123456 &gt; /tmp/mysql_restore.sql</userinput>
 </programlisting>
 
         <para>
-          This will create a small text file in the
-          <filename>/tmp</filename> directory which will show the SQL
-          statements around the time the deleterious SQL statement was
-          executed. You would then open this file with a text editor and
-          look for the statement that you don't want to repeat. Once the
-          position numbers in the binary log are determined for stopping
-          and resuming the recovery, make note of them. Positions are
-          labeled with <literal>log_pos</literal> followed by a number.
-          After restoring the previous backup file, using the position
-          numbers, you would then enter something like the following
-          from the command-line:
+          This command creates a small text file in the
+          <filename>/tmp</filename> directory that contains the SQL
+          statements around the time that the deleterious SQL statement
+          was executed. Open this file with a text editor and look for
+          the statement that you don't want to repeat. Determine the
+          positions in the binary log for stopping and resuming the
+          recovery and make note of them. Positions are labeled as
+          <literal>log_pos</literal> followed by a number. After
+          restoring the previous backup file, use the position numbers
+          to process the binary log file. For example, you would use
+          commands something like these:
         </para>
 
 <programlisting>
-mysqlbinlog --stop-position="368312" /var/log/mysql/bin.123456 \
-    | mysql -u <replaceable>root</replaceable> -p<replaceable>mypwd</replaceable> 
+shell&gt; <userinput>mysqlbinlog --stop-position="368312" /var/log/mysql/bin.123456 \</userinput>
+         <userinput>| mysql -u root -p</userinput>
 
-mysqlbinlog --start-position="368315" /var/log/mysql/bin.123456 \
-    | mysql -u <replaceable>root</replaceable> -p<replaceable>mypwd</replaceable> \ 
+shell&gt; <userinput>mysqlbinlog --start-position="368315" /var/log/mysql/bin.123456 \</userinput>
+         <userinput>| mysql -u root -p</userinput>
 </programlisting>
 
         <para>
-          The first line above will recover all of the transactions up
-          until the stop position given. The next line will recover all
+          The first command recovers all the transactions up until the
+          stop position given. The second command recovers all
           transactions from the starting position given until the end of
           the binary log. Because the output of
           <command>mysqlbinlog</command> includes <literal>SET
@@ -22053,10 +22052,10 @@
       </para>
 
       <para>
-        To be able to know which different binary log files have been
-        used, <command>mysqld</command> also creates a binary log index
-        file that contains the names of all used binary log files. By
-        default this has the same name as the binary log file, with the
+        To keep track of which binary log files have been used,
+        <command>mysqld</command> also creates a binary log index file
+        that contains the names of all used binary log files. By default
+        this has the same name as the binary log file, with the
         extension <literal>'.index'</literal>. You can change the name
         of the binary log index file with the
         <option>--log-bin-index[=<replaceable>file_name</replaceable>]</option>

Modified: trunk/refman-5.0/functions.xml
===================================================================
--- trunk/refman-5.0/functions.xml	2006-01-29 05:00:13 UTC (rev 1096)
+++ trunk/refman-5.0/functions.xml	2006-01-29 05:00:39 UTC (rev 1097)
@@ -783,8 +783,8 @@
               <secondary>with ODBC</secondary>
             </indexterm>
 
-            To be able to work well with ODBC programs, MySQL supports
-            the following extra features when using <literal>IS
+            To work well with ODBC programs, MySQL supports the
+            following extra features when using <literal>IS
             NULL</literal>:
           </para>
 
@@ -9161,7 +9161,7 @@
           <literal>ALTER TABLE</literal> or <literal>CREATE
           INDEX</literal>. For large datasets, it is much faster to load
           your data into a table that has no <literal>FULLTEXT</literal>
-          index and then create the index afterwards, than to load data
+          index and then create the index after that, than to load data
           into a table that has an existing <literal>FULLTEXT</literal>
           index.
         </para>

Modified: trunk/refman-5.0/storage-engines.xml
===================================================================
--- trunk/refman-5.0/storage-engines.xml	2006-01-29 05:00:13 UTC (rev 1096)
+++ trunk/refman-5.0/storage-engines.xml	2006-01-29 05:00:39 UTC (rev 1097)
@@ -3012,12 +3012,11 @@
 
         <listitem>
           <para>
-            To be able to roll back transactions, the
-            <literal>BDB</literal> storage engine maintains log files.
-            For maximum performance, you can use the
-            <option>--bdb-logdir</option> option to place the
-            <literal>BDB</literal> logs on a different disk than the one
-            where your databases are located.
+            To support transaction rollback, the <literal>BDB</literal>
+            storage engine maintains log files. For maximum performance,
+            you can use the <option>--bdb-logdir</option> option to
+            place the <literal>BDB</literal> logs on a different disk
+            than the one where your databases are located.
           </para>
         </listitem>
 

Modified: trunk/refman-5.0/triggers.xml
===================================================================
--- trunk/refman-5.0/triggers.xml	2006-01-29 05:00:13 UTC (rev 1096)
+++ trunk/refman-5.0/triggers.xml	2006-01-29 05:00:39 UTC (rev 1097)
@@ -524,7 +524,7 @@
       (<literal><replaceable>table_name</replaceable>.<replaceable>trigger_name</replaceable></literal>).
       When upgrading from a previous version of MySQL 5 to MySQL 5.0.10
       or newer, you must drop all triggers <emphasis>before
-      upgrading</emphasis> and re-create them afterwards, or else
+      upgrading</emphasis> and re-create them afterward, or else
       <literal>DROP TRIGGER</literal> does not work after the upgrade.
       See <xref linkend="upgrading-from-4-1"/>, for a suggested upgrade
       procedure.

Modified: trunk/refman-5.1/client-utility-programs.xml
===================================================================
--- trunk/refman-5.1/client-utility-programs.xml	2006-01-29 05:00:13 UTC (rev 1096)
+++ trunk/refman-5.1/client-utility-programs.xml	2006-01-29 05:00:39 UTC (rev 1097)
@@ -6114,7 +6114,7 @@
           you to perform point-in-time recovery using the
           <option>--stop-datetime</option> option (to be able to say,
           for example, <quote>roll forward my databases to how they were
-          today at 10:30 AM</quote>).
+          today at 10:30 a.m.</quote>).
         </para>
 
         <para>

Modified: trunk/refman-5.1/custom-engine.xml
===================================================================
--- trunk/refman-5.1/custom-engine.xml	2006-01-29 05:00:13 UTC (rev 1096)
+++ trunk/refman-5.1/custom-engine.xml	2006-01-29 05:00:39 UTC (rev 1097)
@@ -1756,7 +1756,7 @@
         TABLE</literal> operation and store it for future use. The
         reasoning behind this is that the index information is most
         readily available during table and index creation and is not as
-        easily retrieved afterwards.
+        easily retrieved afterward.
       </para>
 
       <para>
@@ -2691,9 +2691,9 @@
 
       <para>
         During a commit operation, all changes made during a transaction
-        are made permanent and afterwards a rollback operation is not
-        possible. Depending on the transaction isolation used, this may
-        be the first time such changes are visible to other threads.
+        are made permanent and a rollback operation is not possible
+        after that. Depending on the transaction isolation used, this
+        may be the first time such changes are visible to other threads.
       </para>
 
       <para>

Modified: trunk/refman-5.1/database-administration.xml
===================================================================
--- trunk/refman-5.1/database-administration.xml	2006-01-29 05:00:13 UTC (rev 1096)
+++ trunk/refman-5.1/database-administration.xml	2006-01-29 05:00:39 UTC (rev 1097)
@@ -18877,7 +18877,7 @@
         </para>
 
         <para>
-          Assume that we make a backup on Sunday at 1 PM, when load is
+          Assume that we make a backup on Sunday at 1 p.m., when load is
           low. The following command makes a full backup of all our
           <literal>InnoDB</literal> tables in all databases:
         </para>
@@ -19016,18 +19016,18 @@
         </itemizedlist>
 
         <para>
-          On Monday at 1 PM, we can create an incremental backup by
+          On Monday at 1 p.m., we can create an incremental backup by
           flushing the logs to begin a new binary log file. For example,
           executing a <command>mysqladmin flush-logs</command> command
           creates <filename>gbichot2-bin.000008</filename>. All changes
-          between the Sunday 1 PM full backup and Monday 1 PM will be in
-          the <filename>gbichot2-bin.000007</filename> file. This
+          between the Sunday 1 p.m. full backup and Monday 1 p.m. will
+          be in the <filename>gbichot2-bin.000007</filename> file. This
           incremental backup is important, so it's a good idea to copy
           it to a safe place. (For example, back it up on tape or DVD,
-          or copy it to another machine.) On Tuesday at 1 PM, execute
+          or copy it to another machine.) On Tuesday at 1 p.m., execute
           another <command>mysqladmin flush-logs</command> command. All
-          changes between Monday 1 PM and Tuesday 1 PM will be in the
-          <filename>gbichot2-bin.000008</filename> file (which also
+          changes between Monday 1 p.m. and Tuesday 1 p.m. will be in
+          the <filename>gbichot2-bin.000008</filename> file (which also
           should be copied somewhere safe).
         </para>
 
@@ -19062,10 +19062,10 @@
 
         <para>
           Now, suppose that we have a catastrophic crash on Wednesday at
-          8 AM that requires recovery from backups. To recover, first we
-          restore the last full backup we have (the one from Sunday 1
-          PM). The full backup file is just a set of SQL statements, so
-          restoring it is very easy:
+          8 a.m. that requires recovery from backups. To recover, first
+          we restore the last full backup we have (the one from Sunday 1
+          p.m.). The full backup file is just a set of SQL statements,
+          so restoring it is very easy:
         </para>
 
 <programlisting>
@@ -19074,8 +19074,8 @@
 
         <para>
           At this point, the data is restored to its state as of Sunday
-          1 PM. To restore the changes made since then, we must use the
-          incremental backups; that is, the
+          1 p.m.. To restore the changes made since then, we must use
+          the incremental backups; that is, the
           <filename>gbichot2-bin.000007</filename> and
           <filename>gbichot2-bin.000008</filename> binary log files.
           Fetch them if necessary from where they were backed up, and
@@ -19088,8 +19088,8 @@
 
         <para>
           We now have recovered the data to its state as of Tuesday 1
-          PM, but still are missing the changes from that date to the
-          date of the crash. To not miss them, we would have needed to
+          p.m., but still are missing the changes from that date to the
+          date of the crash. To not lose them, we would have needed to
           have the MySQL server store its MySQL binary logs into a safe
           location (RAID disks, SAN, ...) different from the place where
           it stores its data files, so that these logs were not in the
@@ -19098,9 +19098,11 @@
           a different physical device than the one on which the data
           directory resides. That way, the logs are not lost even if the
           device containing the directory is.) If we had done this, we
-          would have the <filename>gbichot2-bin.000009</filename> at
-          hand, and we could apply it to restore the most recent data
-          changes with no loss how it was at the moment of the crash.
+          would have the <filename>gbichot2-bin.000009</filename> file
+          at hand, and we could apply it using
+          <command>mysqlbinlog</command> and <command>mysql</command> to
+          restore the most recent data changes with no loss up to the
+          moment of the crash.
         </para>
 
       </section>
@@ -19167,44 +19169,43 @@
       </indexterm>
 
       <para>
-        If a MySQL server has the binary log enabled, you can use the
+        If a MySQL server has binary logging enabled, you can use the
         <command>mysqlbinlog</command> utility to recover data starting
         from a specified point in time (for example, since your last
         backup) until the present or another specified point in time.
-        For information on enabling the binary log, see
-        <xref linkend="binary-log"/>. For more information on the
+        For information on enabling the binary log and using
         <command>mysqlbinlog</command>, see
-        <xref linkend="mysqlbinlog"/>.
+        <xref linkend="binary-log"/>, and <xref linkend="mysqlbinlog"/>.
       </para>
 
       <para>
-        To be able to restore data from a binary log, you will need to
-        know the path and name of the current binary log file. The path
-        can typically be found in the options file (that is,
+        To restore data from a binary log, you will need to know the
+        path and name of the current binary log file. The path can
+        typically be found in the option file (that is,
         <filename>my.cnf</filename> or <filename>my.ini</filename>,
-        depending on your system). If it's not contained in the options
-        file, it may be given as an option at the command-line when the
-        server is started. The option for enabling binary logging is
-        <option>--log-bin</option>. To determine the name of the current
-        binary log file, enter the following statement in MySQL:
+        depending on your system). If the path is not contained in the
+        option file, it may be given as an option at the command-line
+        when the server is started. The option for enabling binary
+        logging is <option>--log-bin</option>. To determine the name of
+        the current binary log file, issue the following statement:
       </para>
 
 <programlisting>
-SHOW BINLOG EVENTS \G
+mysql&gt; <userinput>SHOW BINLOG EVENTS \G</userinput>
 </programlisting>
 
       <para>
-        If you prefer, you could enter the following from the command
-        line instead:
+        If you prefer, you could execute the following command from the
+        command line instead:
       </para>
 
 <programlisting>
-mysql --user=<replaceable>root</replaceable> -p<replaceable>my_pwd</replaceable> -E -e 'SHOW BINLOG EVENTS'
+shell&gt; <userinput>mysql --user=root -p -E -e "SHOW BINLOG EVENTS"</userinput>
 </programlisting>
 
       <para>
-        Replace the password <replaceable>my_pwd</replaceable> with the
-        <replaceable>root</replaceable> password for your server.
+        Enter the <literal>root</literal> password for your server when
+        <command>mysql</command> prompts you for it.
       </para>
 
       <section id="point-in-time-recovery-times">
@@ -19212,46 +19213,44 @@
         <title>&title-point-in-time-recovery-times;</title>
 
         <para>
-          As of version 4.1.4 of MySQL, the
-          <option>--start-date</option> and the
-          <option>--stop-date</option> options are available for
-          <command>mysqlbinlog</command> to specify the start and end
-          times in the <literal>DATETIME</literal> format. As an
-          example, suppose that exactly at 10:00 a.m. today (today being
-          April 20, 2005) an SQL statement was executed which deleted a
-          large table. To restore the table and data, you could restore
-          the previous night's backup, and then enter the following:
+          To indicate the start and end times for recovery, specify the
+          <option>--start-date</option> and <option>--stop-date</option>
+          options for <command>mysqlbinlog</command>, in
+          <literal>DATETIME</literal> format. As an example, suppose
+          that exactly at 10:00 a.m. on April 20, 2005 an SQL statement
+          was executed that deleted a large table. To restore the table
+          and data, you could restore the previous night's backup, and
+          then execute the following command:
         </para>
 
 <programlisting>
-mysqlbinlog --stop-date="2005-04-20 9:59:59" /var/log/mysql/bin.123456 \
-     | mysql -u <replaceable>root</replaceable> -p<replaceable>mypwd</replaceable>
+shell&gt; <userinput>mysqlbinlog --stop-date="2005-04-20 9:59:59" \</userinput>
+         <userinput>/var/log/mysql/bin.123456 | mysql -u root -p</userinput>
 </programlisting>
 
         <para>
-          This will recover all of the data up until the date and time
-          given as a <literal>DATETIME</literal> format for the
-          <option>--stop-date</option> option. If you did not detect the
-          erroneous SQL statement that was entered until hours later,
-          you will probably want to recover the activity that occurred
-          afterwards, as well. Based on this, you could run the
+          This command recovers all of the data up until the date and
+          time given by the <option>--stop-date</option> option. If you
+          did not detect the erroneous SQL statement that was entered
+          until hours later, you will probably also want to recover the
+          activity that occurred afterward. Based on this, you could run
           <command>mysqlbinlog</command> again with a start date and
-          time like so:
+          time, like so:
         </para>
 
 <programlisting>
-mysqlbinlog --start-date="2005-04-20 10:01:00" /var/log/mysql/bin.123456 \
-     | mysql -u <replaceable>root</replaceable> -p<replaceable>mypwd</replaceable> \
+shell&gt; <userinput>mysqlbinlog --start-date="2005-04-20 10:01:00" \</userinput>
+         <userinput>/var/log/mysql/bin.123456 | mysql -u root -p</userinput>
 </programlisting>
 
         <para>
-          In this line, the SQL statements logged from 10:01 a.m. will
-          be run. The combination of executing of the previous night's
-          dump file and the two lines of the
-          <command>mysqlbinlog</command> will restore everything up
+          In this command, the SQL statements logged from 10:01 a.m. on
+          will be re-executed. The combination of restoring of the
+          previous night's dump file and the two
+          <command>mysqlbinlog</command> commands restores everything up
           until one second before 10:00 a.m. and everything from 10:01
           a.m. on. You should examine the log to be sure of the exact
-          times. The next section explains how this might be done.
+          times. The next section explains how to do this.
         </para>
 
       </section>
@@ -19261,52 +19260,52 @@
         <title>&title-point-in-time-recovery-positions;</title>
 
         <para>
-          Instead of specifying dates and times, the options
+          Instead of specifying dates and times, the
           <option>--start-position</option> and
-          <option>--stop-position</option> for
-          <command>mysqlbinlog</command> could be used for specifying
-          log positions. They work the same as the start and stop date
+          <option>--stop-position</option> options for
+          <command>mysqlbinlog</command> can be used for specifying log
+          positions. They work the same as the start and stop date
           options, except that position numbers from the log are given.
           Using log positions may a be more accurate recovery method,
           especially if many transactions occurred around the same time
           as a damaging SQL statement. To determine the position
           numbers, you could run <command>mysqlbinlog</command> for a
-          range of times around when the unwanted transaction was
+          range of times near the time when the unwanted transaction was
           executed, but redirect the results to a text file for
           examination. This can be done like so:
         </para>
 
 <programlisting>
-mysqlbinlog --start-date="2005-04-20 9:55:00" \
-      --stop-date="2005-04-20 10:05:00" \
-      /var/log/mysql/bin.123456 &gt; /tmp/mysql_restore.sql
+shell&gt; <userinput>mysqlbinlog --start-date="2005-04-20 9:55:00" \</userinput>
+         <userinput>--stop-date="2005-04-20 10:05:00" \</userinput>
+         <userinput>/var/log/mysql/bin.123456 &gt; /tmp/mysql_restore.sql</userinput>
 </programlisting>
 
         <para>
-          This will create a small text file in the
-          <filename>/tmp</filename> directory which will show the SQL
-          statements around the time the deleterious SQL statement was
-          executed. You would then open this file with a text editor and
-          look for the statement that you don't want to repeat. Once the
-          position numbers in the binary log are determined for stopping
-          and resuming the recovery, make note of them. Positions are
-          labeled with <literal>log_pos</literal> followed by a number.
-          After restoring the previous backup file, using the position
-          numbers, you would then enter something like the following
-          from the command-line:
+          This command creates a small text file in the
+          <filename>/tmp</filename> directory that contains the SQL
+          statements around the time that the deleterious SQL statement
+          was executed. Open this file with a text editor and look for
+          the statement that you don't want to repeat. Determine the
+          positions in the binary log for stopping and resuming the
+          recovery and make note of them. Positions are labeled as
+          <literal>log_pos</literal> followed by a number. After
+          restoring the previous backup file, use the position numbers
+          to process the binary log file. For example, you would use
+          commands something like these:
         </para>
 
 <programlisting>
-mysqlbinlog --stop-position="368312" /var/log/mysql/bin.123456 \
-    | mysql -u <replaceable>root</replaceable> -p<replaceable>mypwd</replaceable> 
+shell&gt; <userinput>mysqlbinlog --stop-position="368312" /var/log/mysql/bin.123456 \</userinput>
+         <userinput>| mysql -u root -p</userinput>
 
-mysqlbinlog --start-position="368315" /var/log/mysql/bin.123456 \
-    | mysql -u <replaceable>root</replaceable> -p<replaceable>mypwd</replaceable> \ 
+shell&gt; <userinput>mysqlbinlog --start-position="368315" /var/log/mysql/bin.123456 \</userinput>
+         <userinput>| mysql -u root -p</userinput>
 </programlisting>
 
         <para>
-          The first line above will recover all of the transactions up
-          until the stop position given. The next line will recover all
+          The first command recovers all the transactions up until the
+          stop position given. The second command recovers all
           transactions from the starting position given until the end of
           the binary log. Because the output of
           <command>mysqlbinlog</command> includes <literal>SET
@@ -22062,10 +22061,10 @@
       </para>
 
       <para>
-        To be able to know which different binary log files have been
-        used, <command>mysqld</command> also creates a binary log index
-        file that contains the names of all used binary log files. By
-        default this has the same name as the binary log file, with the
+        To keep track of which binary log files have been used,
+        <command>mysqld</command> also creates a binary log index file
+        that contains the names of all used binary log files. By default
+        this has the same name as the binary log file, with the
         extension <literal>'.index'</literal>. You can change the name
         of the binary log index file with the
         <option>--log-bin-index[=<replaceable>file_name</replaceable>]</option>

Modified: trunk/refman-5.1/functions.xml
===================================================================
--- trunk/refman-5.1/functions.xml	2006-01-29 05:00:13 UTC (rev 1096)
+++ trunk/refman-5.1/functions.xml	2006-01-29 05:00:39 UTC (rev 1097)
@@ -776,8 +776,8 @@
               <secondary>with ODBC</secondary>
             </indexterm>
 
-            To be able to work well with ODBC programs, MySQL supports
-            the following extra features when using <literal>IS
+            To work well with ODBC programs, MySQL supports the
+            following extra features when using <literal>IS
             NULL</literal>:
           </para>
 
@@ -9105,7 +9105,7 @@
           <literal>ALTER TABLE</literal> or <literal>CREATE
           INDEX</literal>. For large datasets, it is much faster to load
           your data into a table that has no <literal>FULLTEXT</literal>
-          index and then create the index afterwards, than to load data
+          index and then create the index after that, than to load data
           into a table that has an existing <literal>FULLTEXT</literal>
           index.
         </para>

Modified: trunk/refman-5.1/partitioning.xml
===================================================================
--- trunk/refman-5.1/partitioning.xml	2006-01-29 05:00:13 UTC (rev 1096)
+++ trunk/refman-5.1/partitioning.xml	2006-01-29 05:00:39 UTC (rev 1097)
@@ -2406,7 +2406,7 @@
         same <literal>ALTER TABLE ... DROP PARTITION</literal> syntax as
         use for dropping <literal>RANGE</literal> partitions. However,
         there is one important difference in the effect this has on your
-        use of the table afterwards: You can no longer insert into the
+        use of the table afterward: You can no longer insert into the
         table any rows having any of the values that were included in
         the value list defining the deleted partition. (See
         <xref linkend="partitioning-list"/>, for an example.)

Modified: trunk/refman-5.1/storage-engines.xml
===================================================================
--- trunk/refman-5.1/storage-engines.xml	2006-01-29 05:00:13 UTC (rev 1096)
+++ trunk/refman-5.1/storage-engines.xml	2006-01-29 05:00:39 UTC (rev 1097)
@@ -3011,12 +3011,11 @@
 
         <listitem>
           <para>
-            To be able to roll back transactions, the
-            <literal>BDB</literal> storage engine maintains log files.
-            For maximum performance, you can use the
-            <option>--bdb-logdir</option> option to place the
-            <literal>BDB</literal> logs on a different disk than the one
-            where your databases are located.
+            To support transaction rollback, the <literal>BDB</literal>
+            storage engine maintains log files. For maximum performance,
+            you can use the <option>--bdb-logdir</option> option to
+            place the <literal>BDB</literal> logs on a different disk
+            than the one where your databases are located.
           </para>
         </listitem>
 

Modified: trunk/refman-5.1/triggers.xml
===================================================================
--- trunk/refman-5.1/triggers.xml	2006-01-29 05:00:13 UTC (rev 1096)
+++ trunk/refman-5.1/triggers.xml	2006-01-29 05:00:39 UTC (rev 1097)
@@ -485,7 +485,7 @@
       older than MySQL 5.0.10 to 5.0.10 or newer &mdash; including all
       MySQL &current-series; releases &mdash; you must drop all triggers
       <emphasis>before upgrading</emphasis> and re-create them
-      afterwards, or else <literal>DROP TRIGGER</literal> does not work
+      afterward, or else <literal>DROP TRIGGER</literal> does not work
       after the upgrade. See <xref linkend="upgrading-from-5-0"/>, for a
       suggested upgrade procedure.
     </para>

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