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 … INTO
+ TABLE</literal> Sybase SQL extension. Instead, MySQL Server
+ supports the <literal>INSERT INTO … 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 … INTO
+ OUTFILE</literal> or <literal>CREATE TABLE …
+ 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 <> 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 … INTO
+ TABLE</literal> Sybase SQL extension. Instead, MySQL Server
+ supports the <literal>INSERT INTO … 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 … INTO
+ OUTFILE</literal> or <literal>CREATE TABLE …
+ 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 …
+ 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 <> 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 … INTO
+ TABLE</literal> Sybase SQL extension. Instead, MySQL Server
+ supports the <literal>INSERT INTO … 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 … INTO
+ OUTFILE</literal> or <literal>CREATE TABLE …
+ 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 …
+ 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 <> 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-common | paul | 5 Jan |
