Author: jstephens
Date: 2006-10-30 06:26:22 +0100 (Mon, 30 Oct 2006)
New Revision: 3793
Log:
5.0/5.1 FAQs - spellcheck, fix some boo-boos, reformat.
Modified:
trunk/refman-5.0/faqs.xml
trunk/refman-5.1/faqs.xml
Modified: trunk/refman-5.0/faqs.xml
===================================================================
--- trunk/refman-5.0/faqs.xml 2006-10-29 07:13:55 UTC (rev 3792)
+++ trunk/refman-5.0/faqs.xml 2006-10-30 05:26:22 UTC (rev 3793)
Changed blocks: 33, Lines Added: 66, Lines Deleted: 68; 17949 bytes
@@ -180,8 +180,7 @@
<question>
<para>
- Does MySQL ¤t-series; work with multi-core
- processors?
+ Does MySQL ¤t-series; work with multi-core processors?
</para>
</question>
@@ -664,7 +663,7 @@
<answer>
<para>
- It is always good practice to use a clear naming scheme for
+ It is always good practise to use a clear naming scheme for
your stored routines. You can manage stored procedures with
<literal>CREATE [FUNCTION|PROCEDURE]</literal>,
<literal>ALTER [FUNCTION|PROCEDURE]</literal>, <literal>DROP
@@ -859,9 +858,10 @@
<answer>
<para>
- Not in MySQL ¤t-series;. The SQL standard
- <literal>SIGNAL</literal> and <literal>RESIGNAL</literal>
- statements are on the TODO.
+ Not in MySQL ¤t-series;. We intend to implement the
+ SQL standard <literal>SIGNAL</literal> and
+ <literal>RESIGNAL</literal> statements in a future MySQL
+ release.
</para>
</answer>
@@ -1173,7 +1173,7 @@
<answer>
<para>
- Not explicitly. MySQL does have specific special behavior
+ Not explicitly. MySQL does have specific special behaviour
for some <literal>TIMESTAMP</literal> columns, as well as
for columns which are defined using
<literal>AUTO_INCREMENT</literal>.
@@ -1480,7 +1480,7 @@
<question>
<para>
- Does MySQL ¤t-series; have materialized views?
+ Does MySQL ¤t-series; have materialised views?
</para>
</question>
@@ -1644,7 +1644,7 @@
<para>
No. Since applications may rely on a certain standard
- structure, this should not be modified.For this reason,
+ structure, this should not be modified. For this reason,
<emphasis>MySQL AB cannot support bugs or other issues which
result from modifying <literal>INFORMATION_SCHEMA</literal>
tables or data</emphasis>.
@@ -1730,7 +1730,7 @@
Internal <literal>RAID</literal> for
<literal>MyISAM</literal> tables was also removed in
MySQL 5.0. This was formerly used to allow large
- tables in filesystems that did not support filesizes
+ tables in filesystems that did not support file sizes
greater than 2GB. All modern filesystems allow for
larger tables; in addition, there are now other
solutions such as <literal>MERGE</literal> tables and
@@ -1815,7 +1815,7 @@
<para>
Most ¤t-series; binaries have SSL enabled for
- client-server connections thsat are secured, authenticated,
+ client-server connections that are secured, authenticated,
or both. However, the YaSSL library currently does not
compile on all platforms. See
<xref linkend="secure-connections"/>, for a complete listing
@@ -1991,16 +1991,19 @@
[pd] Following para isn't so clear...
</remark>
+ <remark role="note">
+ [js] Reworded. Hopefully this is an improvement.
+ </remark>
+
<para>
- Regardless of which of the two methods you use, afterward follow
- the instructions for the case when you have a snapshot and have
- recorded the log filename and offset. You can use the same
- snapshot to set up several slaves. Once you have the snapshot of
- the master, you can wait to set up a slave as long as the binary
- logs of the master are left intact. The two practical limitations
- on the length of time you can wait are the amount of disk space
- available to retain binary logs on the master and the length of
- time it takes the slave to catch up.
+ Regardless of the method used to obtain the snapshot, log
+ filename, and offset, you can use the same snapshot to set up
+ several slaves. Once you have the snapshot of the master, you can
+ wait to set up a slave as long as the binary logs of the master
+ are left intact. The two practical limitations on the length of
+ time you can wait are the amount of disk space available to retain
+ binary logs on the master and the length of time it takes the
+ slave to catch up.
</para>
<para>
@@ -2079,7 +2082,7 @@
</programlisting>
<para>
- Record the replication cooredinates (the log filename and
+ Record the replication coordinates (the log filename and
offset) from the output of the <literal>SHOW</literal>
statement.
</para>
@@ -2142,12 +2145,12 @@
</para>
<para>
- You should also realize that two-way replication actually does not
+ You should also realise that two-way replication actually does not
improve performance very much (if at all) as far as updates are
concerned. Each server must do the same number of updates, just as
you would have a single server do. The only difference is that
there is a little less lock contention, because the updates
- originating on another server are serialized in one slave thread.
+ originating on another server are serialised in one slave thread.
Even this benefit might be offset by network delays.
</para>
@@ -2169,8 +2172,8 @@
<para>
<emphasis role="bold">A</emphasis>: You should set up one server
as the master and direct all writes to it. Then configure as many
- slaves as you have the budget and rackspace for, and distribute
- the reads among the master and the slaves. You can also start the
+ slaves as you have the budget and space for, and distribute the
+ reads among the master and the slaves. You can also start the
slaves with the <option>--skip-innodb</option>,
<option>--skip-bdb</option>,
<option>--low-priority-updates</option>, and
@@ -2255,7 +2258,7 @@
conversion script. Ideally, your code uses consistent programming
style conventions. If not, then you are probably better off
rewriting it anyway, or at least going through and manually
- regularizing it to use a consistent style.
+ regularising it to use a consistent style.
</para>
<para>
@@ -2578,10 +2581,10 @@
</para>
<para>
- Note that there is no synchronization between the different
+ Note that there is no synchronisation between the different
slaves to a master. Some slaves might be ahead of others. This
means that the concept outlined in the previous example might
- not work. In practice, however, the relay logs of different
+ not work. In practise, however, the relay logs of different
slaves will most likely not be far behind the master, so it
would work, anyway (but there is no guarantee).
</para>
@@ -2837,7 +2840,7 @@
<para>
A MySQL Cluster has both a physical and logical
- organization, with computers being the physical elements.
+ organisation, with computers being the physical elements.
The logical or functional elements of a cluster are referred
to as <firstterm>nodes</firstterm>, and a computer housing a
cluster node is sometimes referred to as a
@@ -3006,8 +3009,8 @@
RAM, then the system will attempt to use swap space up to
the limit set for <literal>DataMemory</literal>. However,
this will at best result in severely degraded performance,
- and may cuase the node to be dropped due to slow response
- time (missed hearbeats). We do not recommend on relying on
+ and may cause the node to be dropped due to slow response
+ time (missed heartbeats). We do not recommend on relying on
disk swapping in a production environment for this reason.
In any case, once the <literal>DataMemory</literal> limit is
reached, any operations requiring additional memory (such as
@@ -3094,7 +3097,7 @@
on tables where <literal>USING HASH</literal> was not used
in creating primary and unique keys. This is due to the fact
that less memory is required (because no ordered indexes are
- created), and that less CPU must be utilized (because fewer
+ created), and that less CPU must be utilised (because fewer
indexes must be read and possibly updated). However, it also
means that queries that could otherwise use range scans must
be satisfied by other means, which can result in slower
@@ -3269,7 +3272,7 @@
<answer>
<para>
- No. Although some specialized commands are used to manage
+ No. Although some specialised commands are used to manage
and configure the cluster itself, only standard (My)SQL
queries and commands are required for the following
operations:
@@ -3517,7 +3520,7 @@
All committed transactions are logged. Therefore, although
it is possible that some data could be lost in the event of
a catastrophe, this should be quite limited. Data loss can
- be further reduced by minimizing the number of operations
+ be further reduced by minimising the number of operations
per transaction. (It is not a good idea to perform large
numbers of operations per transaction in any case.)
</para>
@@ -3644,7 +3647,7 @@
<para>
In a future MySQL Cluster release series, we hope to
implement a <quote>hot</quote> reconfiguration capability
- for MySQL Cluster to minimize (if not eliminate) the
+ for MySQL Cluster to minimise (if not eliminate) the
requirement for restarting the cluster when adding new
nodes. However, this is not planned for MySQL
¤t-series;.
@@ -3701,7 +3704,7 @@
<listitem>
<para>
Only complete rollbacks for transactions are supported.
- Partial rollbacks and rollbacks to savepoints are not
+ Partial rollbacks and rollbacks to save points are not
supported.
</para>
</listitem>
@@ -3876,7 +3879,7 @@
arises when no single node group has all its nodes alive, in
which case network partitioning (the
<quote>split-brain</quote> scenario) becomes possible. Then
- an arbitrator is required. All cluster nodes recognize the
+ an arbitrator is required. All cluster nodes recognise the
same node as the arbitrator, which is normally the
management server; however, it is possible to configure any
of the MySQL Servers in the cluster to act as the arbitrator
@@ -3991,8 +3994,8 @@
Each of these commands must be run from a system shell on
the machine housing the affected node. (You do not have to
be physically present at the machine — a remote login
- shgell can be used for this purpose.) You can verify that
- the cluster is running by starting the MGM management client
+ shell can be used for this purpose.) You can verify that the
+ cluster is running by starting the MGM management client
<command>ndb_mgm</command> on the machine housing the MGM
node and issuing the <literal>SHOW</literal> or <literal>ALL
STATUS</literal> command.
@@ -4101,11 +4104,11 @@
<para>
Yes, so long as all machines and operating systems have the
- same endianness (all big-endian or all little-endian). It is
- also possible to use different MySQL Cluster releases on
- different nodes. However, we recommend this be done only as
- part of a rolling upgrade procedure (see
- <xref linkend="mysql-cluster-rolling-restart"/>).
+ same <quote>endianness</quote> (all big-endian or all
+ little-endian). It is also possible to use different MySQL
+ Cluster releases on different nodes. However, we recommend
+ this be done only as part of a rolling upgrade procedure
+ (see <xref linkend="mysql-cluster-rolling-restart"/>).
</para>
</answer>
@@ -4179,7 +4182,7 @@
<answer>
<para>
- MySQL user accounts asnd privileges are not automatically
+ MySQL user accounts and privileges are not automatically
propagated between different MySQL servers accessing the
same MySQL Cluster. Therefore, you must make sure that these
are copied between the SQL nodes yourself.
@@ -4469,17 +4472,12 @@
</programlisting>
</para>
- <remark role="todo">
- [js] Following ref should point to
- faqs-cjk-gui-browser-apis.
- </remark>
-
<para>
It is also possible that there are issues with the API
configuration setting being used in your application;
see <citetitle>Why does my GUI front end or browser not
- diplay CJK characters correctly...?</citetitle> for more
- information.
+ display CJK characters correctly...?</citetitle> for
+ more information.
</para>
</listitem>
@@ -4697,11 +4695,11 @@
<para>
MySQL supports the <literal>sjis</literal>,
<literal>ujis</literal>, <literal>cp932</literal>, and
- eucjpms character sets, as well as Unicode. A common need is
- to convert between character sets. For example, there might
- be a Unix server (typically with <literal>sjis</literal> or
- <literal>ujis</literal>) and a Windows client (typically
- with <literal>cp932</literal>).
+ <literal>eucjpms</literal> character sets, as well as
+ Unicode. A common need is to convert between character sets.
+ For example, there might be a Unix server (typically with
+ <literal>sjis</literal> or <literal>ujis</literal>) and a
+ Windows client (typically with <literal>cp932</literal>).
</para>
<para>
@@ -5262,8 +5260,8 @@
<secondary>Access, PHP, etc.</secondary>
</indexterm>
- <para id="faqs-cjk-gui-browser-apis">
- Why does my GUI front end or browser not diplay CJK
+ <para>
+ Why does my GUI front end or browser not display CJK
characters correctly in my application using Access, PHP, or
another API?
</para>
@@ -5278,7 +5276,7 @@
<command>mysql.exe</command>), and try the same query there.
If <command>mysql</command> responds correctly, then the
trouble may be that your application interface requires
- initialization. Use <command>mysql</command> to tell you
+ initialisation. Use <command>mysql</command> to tell you
what character set or sets it uses with the statement
<literal>SHOW VARIABLES LIKE 'char%';</literal>. If you are
using Access, then you are most likely connecting with
@@ -5355,7 +5353,7 @@
do with assumptions made by the browser. Sometimes adding or
changing a <literal><meta></literal> tag suffices to
correct the problem: for example, to insure that the user
- agent interpets page content as <literal>UTF-8</literal>,
+ agent interprets page content as <literal>UTF-8</literal>,
you should include <literal><meta
http-equiv="Content-Type" content="text/html;
charset=utf-8"></literal> in the
@@ -5559,7 +5557,7 @@
even very simple searches such as <literal>LIKE
'_A%'</literal> fail. The solution is to use a regular CJK
character set in the first place, or to convert to a CJK
- character character set before comparing.
+ character set before comparing.
</para>
<para>
@@ -5809,11 +5807,11 @@
<ulink url="http://www.unicode.org/Public/UCA/4.0.0/allkeys-4.0.0.txt"/>.
This is not the first table you will find by navigating from
the <literal>unicode.org</literal> home page, because MySQL
- uses the older 4.0.0 <quote>allkeys</quote> tablethsan the
- more recent 4.1.0 table. This is because we are very wary
- about changing ordering which affects indexes, lest we bring
- about situations such as that reported in Bug #16526,
- illustrated as follows:
+ uses the older 4.0.0 <quote>allkeys</quote> table, rather
+ than the more recent 4.1.0 table. This is because we are
+ very wary about changing ordering which affects indexes,
+ lest we bring about situations such as that reported in Bug
+ #16526, illustrated as follows:
<programlisting>
mysql< <userinput>CREATE TABLE tj (s1 CHAR(1) CHARACTER SET utf8 COLLATE utf8_unicode_ci);</userinput>
@@ -6081,7 +6079,7 @@
</para>
<para>
- Bug #4745 is a request for a specialized Vietnamese
+ Bug #4745 is a request for a specialised Vietnamese
collation, which we might add in the future if there is
sufficient demand for it.
</para>
Modified: trunk/refman-5.1/faqs.xml
===================================================================
--- trunk/refman-5.1/faqs.xml 2006-10-29 07:13:55 UTC (rev 3792)
+++ trunk/refman-5.1/faqs.xml 2006-10-30 05:26:22 UTC (rev 3793)
Changed blocks: 33, Lines Added: 62, Lines Deleted: 64; 17532 bytes
@@ -180,8 +180,7 @@
<question>
<para>
- Does MySQL ¤t-series; work with multi-core
- processors?
+ Does MySQL ¤t-series; work with multi-core processors?
</para>
</question>
@@ -664,7 +663,7 @@
<answer>
<para>
- It is always good practice to use a clear naming scheme for
+ It is always good practise to use a clear naming scheme for
your stored routines. You can manage stored procedures with
<literal>CREATE [FUNCTION|PROCEDURE]</literal>,
<literal>ALTER [FUNCTION|PROCEDURE]</literal>, <literal>DROP
@@ -859,9 +858,10 @@
<answer>
<para>
- Not in MySQL ¤t-series;. The SQL standard
- <literal>SIGNAL</literal> and <literal>RESIGNAL</literal>
- statements are on the TODO.
+ Not in MySQL ¤t-series;. We intend to implement the
+ SQL standard <literal>SIGNAL</literal> and
+ <literal>RESIGNAL</literal> statements in a future MySQL
+ release.
</para>
</answer>
@@ -1173,7 +1173,7 @@
<answer>
<para>
- Not explicitly. MySQL does have specific special behavior
+ Not explicitly. MySQL does have specific special behaviour
for some <literal>TIMESTAMP</literal> columns, as well as
for columns which are defined using
<literal>AUTO_INCREMENT</literal>.
@@ -1480,7 +1480,7 @@
<question>
<para>
- Does MySQL ¤t-series; have materialized views?
+ Does MySQL ¤t-series; have materialised views?
</para>
</question>
@@ -1644,7 +1644,7 @@
<para>
No. Since applications may rely on a certain standard
- structure, this should not be modified.For this reason,
+ structure, this should not be modified. For this reason,
<emphasis>MySQL AB cannot support bugs or other issues which
result from modifying <literal>INFORMATION_SCHEMA</literal>
tables or data</emphasis>.
@@ -1730,7 +1730,7 @@
Internal <literal>RAID</literal> for
<literal>MyISAM</literal> tables was also removed in
MySQL 5.0. This was formerly used to allow large
- tables in filesystems that did not support filesizes
+ tables in filesystems that did not support file sizes
greater than 2GB. All modern filesystems allow for
larger tables; in addition, there are now other
solutions such as <literal>MERGE</literal> tables and
@@ -1815,7 +1815,7 @@
<para>
Most ¤t-series; binaries have SSL enabled for
- client-server connections thsat are secured, authenticated,
+ client-server connections that are secured, authenticated,
or both. However, the YaSSL library currently does not
compile on all platforms. See
<xref linkend="secure-connections"/>, for a complete listing
@@ -1991,16 +1991,19 @@
[pd] Following para isn't so clear...
</remark>
+ <remark role="note">
+ [js] Reworded. Hopefully this is an improvement.
+ </remark>
+
<para>
- Regardless of which of the two methods you use, afterward follow
- the instructions for the case when you have a snapshot and have
- recorded the log filename and offset. You can use the same
- snapshot to set up several slaves. Once you have the snapshot of
- the master, you can wait to set up a slave as long as the binary
- logs of the master are left intact. The two practical limitations
- on the length of time you can wait are the amount of disk space
- available to retain binary logs on the master and the length of
- time it takes the slave to catch up.
+ Regardless of the method used to obtain the snapshot, log
+ filename, and offset, you can use the same snapshot to set up
+ several slaves. Once you have the snapshot of the master, you can
+ wait to set up a slave as long as the binary logs of the master
+ are left intact. The two practical limitations on the length of
+ time you can wait are the amount of disk space available to retain
+ binary logs on the master and the length of time it takes the
+ slave to catch up.
</para>
<para>
@@ -2079,7 +2082,7 @@
</programlisting>
<para>
- Record the replication cooredinates (the log filename and
+ Record the replication coordinates (the log filename and
offset) from the output of the <literal>SHOW</literal>
statement.
</para>
@@ -2142,12 +2145,12 @@
</para>
<para>
- You should also realize that two-way replication actually does not
+ You should also realise that two-way replication actually does not
improve performance very much (if at all) as far as updates are
concerned. Each server must do the same number of updates, just as
you would have a single server do. The only difference is that
there is a little less lock contention, because the updates
- originating on another server are serialized in one slave thread.
+ originating on another server are serialised in one slave thread.
Even this benefit might be offset by network delays.
</para>
@@ -2169,8 +2172,8 @@
<para>
<emphasis role="bold">A</emphasis>: You should set up one server
as the master and direct all writes to it. Then configure as many
- slaves as you have the budget and rackspace for, and distribute
- the reads among the master and the slaves. You can also start the
+ slaves as you have the budget and space for, and distribute the
+ reads among the master and the slaves. You can also start the
slaves with the <option>--skip-innodb</option>,
<option>--skip-bdb</option>,
<option>--low-priority-updates</option>, and
@@ -2255,7 +2258,7 @@
conversion script. Ideally, your code uses consistent programming
style conventions. If not, then you are probably better off
rewriting it anyway, or at least going through and manually
- regularizing it to use a consistent style.
+ regularising it to use a consistent style.
</para>
<para>
@@ -2578,10 +2581,10 @@
</para>
<para>
- Note that there is no synchronization between the different
+ Note that there is no synchronisation between the different
slaves to a master. Some slaves might be ahead of others. This
means that the concept outlined in the previous example might
- not work. In practice, however, the relay logs of different
+ not work. In practise, however, the relay logs of different
slaves will most likely not be far behind the master, so it
would work, anyway (but there is no guarantee).
</para>
@@ -2837,7 +2840,7 @@
<para>
A MySQL Cluster has both a physical and logical
- organization, with computers being the physical elements.
+ organisation, with computers being the physical elements.
The logical or functional elements of a cluster are referred
to as <firstterm>nodes</firstterm>, and a computer housing a
cluster node is sometimes referred to as a
@@ -3007,8 +3010,8 @@
RAM, then the system will attempt to use swap space up to
the limit set for <literal>DataMemory</literal>. However,
this will at best result in severely degraded performance,
- and may cuase the node to be dropped due to slow response
- time (missed hearbeats). We do not recommend on relying on
+ and may cause the node to be dropped due to slow response
+ time (missed heartbeats). We do not recommend on relying on
disk swapping in a production environment for this reason.
In any case, once the <literal>DataMemory</literal> limit is
reached, any operations requiring additional memory (such as
@@ -3096,7 +3099,7 @@
on tables where <literal>USING HASH</literal> was not used
in creating primary and unique keys. This is due to the fact
that less memory is required (because no ordered indexes are
- created), and that less CPU must be utilized (because fewer
+ created), and that less CPU must be utilised (because fewer
indexes must be read and possibly updated). However, it also
means that queries that could otherwise use range scans must
be satisfied by other means, which can result in slower
@@ -3271,7 +3274,7 @@
<answer>
<para>
- No. Although some specialized commands are used to manage
+ No. Although some specialised commands are used to manage
and configure the cluster itself, only standard (My)SQL
queries and commands are required for the following
operations:
@@ -3481,7 +3484,7 @@
You can also obtain NDB support by compiling MySQL from
source, but it is not necessary to do so simply to use MySQL
Cluster. To download the latest binary, RPM, or source
- distibution in the MySQL ¤t-series; series, visit
+ distribution in the MySQL ¤t-series; series, visit
<ulink url="&base-url-downloads;mysql/¤t-series;.html"/>.
</para>
@@ -3508,7 +3511,7 @@
All committed transactions are logged. Therefore, although
it is possible that some data could be lost in the event of
a catastrophe, this should be quite limited. Data loss can
- be further reduced by minimizing the number of operations
+ be further reduced by minimising the number of operations
per transaction. (It is not a good idea to perform large
numbers of operations per transaction in any case.)
</para>
@@ -3635,7 +3638,7 @@
<para>
In a future MySQL Cluster release series, we hope to
implement a <quote>hot</quote> reconfiguration capability
- for MySQL Cluster to minimize (if not eliminate) the
+ for MySQL Cluster to minimise (if not eliminate) the
requirement for restarting the cluster when adding new
nodes. However, this is not planned for MySQL
¤t-series;.
@@ -3703,7 +3706,7 @@
<listitem>
<para>
Only complete rollbacks for transactions are supported.
- Partial rollbacks and rollbacks to savepoints are not
+ Partial rollbacks and rollbacks to save points are not
supported.
</para>
</listitem>
@@ -3878,7 +3881,7 @@
arises when no single node group has all its nodes alive, in
which case network partitioning (the
<quote>split-brain</quote> scenario) becomes possible. Then
- an arbitrator is required. All cluster nodes recognize the
+ an arbitrator is required. All cluster nodes recognise the
same node as the arbitrator, which is normally the
management server; however, it is possible to configure any
of the MySQL Servers in the cluster to act as the arbitrator
@@ -3993,8 +3996,8 @@
Each of these commands must be run from a system shell on
the machine housing the affected node. (You do not have to
be physically present at the machine — a remote login
- shgell can be used for this purpose.) You can verify that
- the cluster is running by starting the MGM management client
+ shell can be used for this purpose.) You can verify that the
+ cluster is running by starting the MGM management client
<command>ndb_mgm</command> on the machine housing the MGM
node and issuing the <literal>SHOW</literal> or <literal>ALL
STATUS</literal> command.
@@ -4103,11 +4106,11 @@
<para>
Yes, so long as all machines and operating systems have the
- same endianness (all big-endian or all little-endian). It is
- also possible to use different MySQL Cluster releases on
- different nodes. However, we recommend this be done only as
- part of a rolling upgrade procedure (see
- <xref linkend="mysql-cluster-rolling-restart"/>).
+ same <quote>endianness</quote> (all big-endian or all
+ little-endian). It is also possible to use different MySQL
+ Cluster releases on different nodes. However, we recommend
+ this be done only as part of a rolling upgrade procedure
+ (see <xref linkend="mysql-cluster-rolling-restart"/>).
</para>
</answer>
@@ -4181,7 +4184,7 @@
<answer>
<para>
- MySQL user accounts asnd privileges are not automatically
+ MySQL user accounts and privileges are not automatically
propagated between different MySQL servers accessing the
same MySQL Cluster. Therefore, you must make sure that these
are copied between the SQL nodes yourself.
@@ -4471,17 +4474,12 @@
</programlisting>
</para>
- <remark role="todo">
- [js] Following ref should point to
- faqs-cjk-gui-browser-apis.
- </remark>
-
<para>
It is also possible that there are issues with the API
configuration setting being used in your application;
see <citetitle>Why does my GUI front end or browser not
- diplay CJK characters correctly...?</citetitle> for more
- information.
+ display CJK characters correctly...?</citetitle> for
+ more information.
</para>
</listitem>
@@ -5264,8 +5262,8 @@
<secondary>Access, PHP, etc.</secondary>
</indexterm>
- <para id="faqs-cjk-gui-browser-apis">
- Why does my GUI front end or browser not diplay CJK
+ <para>
+ Why does my GUI front end or browser not display CJK
characters correctly in my application using Access, PHP, or
another API?
</para>
@@ -5280,7 +5278,7 @@
<command>mysql.exe</command>), and try the same query there.
If <command>mysql</command> responds correctly, then the
trouble may be that your application interface requires
- initialization. Use <command>mysql</command> to tell you
+ initialisation. Use <command>mysql</command> to tell you
what character set or sets it uses with the statement
<literal>SHOW VARIABLES LIKE 'char%';</literal>. If you are
using Access, then you are most likely connecting with
@@ -5357,7 +5355,7 @@
do with assumptions made by the browser. Sometimes adding or
changing a <literal><meta></literal> tag suffices to
correct the problem: for example, to insure that the user
- agent interpets page content as <literal>UTF-8</literal>,
+ agent interprets page content as <literal>UTF-8</literal>,
you should include <literal><meta
http-equiv="Content-Type" content="text/html;
charset=utf-8"></literal> in the
@@ -5561,7 +5559,7 @@
even very simple searches such as <literal>LIKE
'_A%'</literal> fail. The solution is to use a regular CJK
character set in the first place, or to convert to a CJK
- character character set before comparing.
+ character set before comparing.
</para>
<para>
@@ -5810,11 +5808,11 @@
<ulink url="http://www.unicode.org/Public/UCA/4.0.0/allkeys-4.0.0.txt"/>.
This is not the first table you will find by navigating from
the <literal>unicode.org</literal> home page, because MySQL
- uses the older 4.0.0 <quote>allkeys</quote> tablethsan the
- more recent 4.1.0 table. This is because we are very wary
- about changing ordering which affects indexes, lest we bring
- about situations such as that reported in Bug #16526,
- illustrated as follows:
+ uses the older 4.0.0 <quote>allkeys</quote> table, rather
+ than the more recent 4.1.0 table. This is because we are
+ very wary about changing ordering which affects indexes,
+ lest we bring about situations such as that reported in Bug
+ #16526, illustrated as follows:
<programlisting>
mysql< <userinput>CREATE TABLE tj (s1 CHAR(1) CHARACTER SET utf8 COLLATE utf8_unicode_ci);</userinput>
@@ -6082,7 +6080,7 @@
</para>
<para>
- Bug #4745 is a request for a specialized Vietnamese
+ Bug #4745 is a request for a specialised Vietnamese
collation, which we might add in the future if there is
sufficient demand for it.
</para>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r3793 - in trunk: refman-5.0 refman-5.1 | jon | 30 Oct |
