Documentation Source Text

Check-in [cfa4627882]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Fix typos in documentation. This is the fix for ticket [9ed3b9626c9462e11a557621152f3e2d4eead482]
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1:cfa4627882e06b105bff7bcefe6a9be7b6d4a22e
User & Date: drh 2009-03-18 14:19:10
References
2009-03-18
14:21 Fixed ticket [9ed3b9626c]: Fixing some typos in the documentation plus 2 other changes artifact: eb689a6fce user: drh
Context
2009-03-18
15:14
Add a new FAQ entry that attempts to explain the difference between single quotes and double quotes. check-in: b405f2eeeb user: drh tags: trunk
14:19
Fix typos in documentation. This is the fix for ticket [9ed3b9626c9462e11a557621152f3e2d4eead482] check-in: cfa4627882 user: drh tags: trunk
2009-03-17
11:07
Fix typo in the rtree.html webpage. CVSTrac ticket #3730. check-in: 61871a4c17 user: drh tags: trunk
Changes
Hide Diffs Side-by-Side Diffs Ignore Whitespace Patch

Changes to pages/arch.in.

   161    161   and 65536 bytes.
   162    162   The page cache is responsible for reading, writing, and
   163    163   caching these chunks.
   164    164   The page cache also provides the rollback and atomic commit abstraction
   165    165   and takes care of locking of the database file.  The
   166    166   B-tree driver requests particular pages from the page cache and notifies
   167    167   the page cache when it wants to modify pages or commit or rollback
   168         -changes and the page cache handles all the messy details of making sure
          168  +changes. The page cache handles all the messy details of making sure
   169    169   the requests are handled quickly, safely, and efficiently.</p>
   170    170   
   171    171   <p>The code to implement the page cache is contained in the single C
   172    172   source file <b>pager.c</b>.  The interface to the page cache subsystem
   173    173   is defined by the header file <b>pager.h</b>.
   174    174   </p>
   175    175   

Changes to pages/atomiccommit.in.

   460    460   then the user space cache must be cleared and reread.  But it is
   461    461   commonly the case that no changes have been made and the user
   462    462   space cache can be reused for a significant performance savings.</p>
   463    463   
   464    464   <br clear="both">
   465    465   <h2>4.0 Rollback</h2>
   466    466   
   467         -<p>An atomic commit is suppose to happen instantaneously.  But the processing
          467  +<p>An atomic commit is supposed to happen instantaneously.  But the processing
   468    468   described above clearly takes a finite amount of time.
   469    469   Suppose the power to the computer were cut
   470    470   part way through the commit operation described above.  In order
   471    471   to maintain the illusion that the changes were instantaneous, we
   472    472   have to "rollback" any partial changes and restore the database to
   473    473   the state it was in prior to the beginning of the transaction.</p>
   474    474   
................................................................................
  1093   1093   synchronous operation and so we think that TRUNCATE will usually be safe
  1094   1094   in the face of power failures.  If you are uncertain about whether or
  1095   1095   not TRUNCATE will be synchronous and atomic on your filesystem and it is
  1096   1096   important to you that your database survive a power loss or operating
  1097   1097   system crash that occurs during the truncation operation, then you might
  1098   1098   consider using a different journaling mode.</p>
  1099   1099   
  1100         -<p>On embedded systems with synchronous filesystems, TRUNCATE is results
         1100  +<p>On embedded systems with synchronous filesystems, TRUNCATE results
  1101   1101   in slower behavior than PERSIST.  The commit operation is the same speed.
  1102   1102   But subsequent transactions are slower following a TRUNCATE because it is
  1103   1103   faster to overwrite existing content than to append to the end of a file.
  1104   1104   New journal file entries will always be appended following a TRUNCATE but
  1105   1105   will usually overwrite with PERSIST.</p>
  1106   1106   
  1107   1107   <h2>8.0 Testing Atomic Commit Behavior</h2>

Changes to pages/cintro.in.

   365    365     The [sqlite3_create_module()] interface is used register new
   366    366     virtual table implementations.
   367    367   </p>
   368    368   
   369    369   <p>
   370    370     The [sqlite3_create_function()] interface creates new SQL functions - 
   371    371     either scalar or aggregate.  The new function implementation typically
   372         -  make use of the following additional interfaces:
          372  +  makes use of the following additional interfaces:
   373    373   </p>
   374    374   
   375    375   <p><ul>
   376    376     <li> [sqlite3_aggregate_context()] </li>
   377    377     <li> [sqlite3_result_int | sqlite3_result()] </li>
   378    378     <li> [sqlite3_user_data()] </li>
   379    379     <li> [sqlite3_value_int | sqlite3_value()] </li>

Changes to pages/datatype3.in.

   355    355   <UL>
   356    356   <LI><b>BINARY</b> - Compares string data using memcmp(), regardless
   357    357                       of text encoding.</LI>
   358    358   <LI><b>NOCASE</b> - The same as binary, except the 26 upper case
   359    359        characters of ASCII are
   360    360        folded to their lower case equivalents before
   361    361        the comparison is performed.  Note that only ASCII characters
   362         -     are case folded.  SQLite does not attempt to due full
          362  +     are case folded.  SQLite does not attempt to do full
   363    363        UTF case folding due to the size of the tables required.</li>
   364    364   
   365    365   <LI><b>RTRIM</b> - The same as binary, except that trailing space
   366    366        characters are ignored.</li>
   367    367   </ul>
   368    368   
   369    369   

Changes to pages/faq.in.

    88     88     </p>
    89     89   }
    90     90   
    91     91   faq {
    92     92     Why doesn't SQLite allow me to use '0' and '0.0' as the primary
    93     93     key on two different rows of the same table?
    94     94   } {
    95         -  <p>Your primary key must have a numeric type.  Change the [datatype] of
    96         -  your primary key to TEXT and it should work.</p>
           95  +  <p>This problem occurs when your primary key is a numeric type.  Change the
           96  +  [datatype] of your primary key to TEXT and it should work.</p>
    97     97   
    98     98     <p>Every row must have a unique primary key.  For a column with a
    99     99     numeric type, SQLite thinks that <b>'0'</b> and <b>'0.0'</b> are the
   100    100     same value because they compare equal to one another numerically.
   101    101     (See the previous question.)  Hence the values are not unique.</p>
   102    102   }
   103    103           

Changes to pages/features.in.

    46     46   <h3>Suggested Uses For SQLite:</h3>
    47     47   
    48     48   <p><ul>
    49     49   <li><p><b>Application File Format.</b>
    50     50   Rather than using fopen() to write XML or some proprietary format into
    51     51   disk files used by your application, use an SQLite database instead.
    52     52   You'll avoid having to write and troubleshoot a parser, your data
    53         -will be more easily accessible and cross-platform, your updates
           53  +will be more easily accessible and cross-platform, and your updates
    54     54   will be transactional.</p></li>
    55     55   
    56     56   <li><p><b>Database For Gadgets.</b>
    57     57   SQLite is popular choice for the database engine in cellphones,
    58     58   PDAs, MP3 players, set-top boxes, and other electronic gadgets.
    59     59   SQLite has a small code footprint, makes efficient use of memory,
    60     60   disk space, and disk bandwidth, is highly reliable, and requires

Changes to pages/lockingv3.in.

    50     50   pager module</a>.
    51     51   The pager module is responsible for making SQLite "ACID" (Atomic,
    52     52   Consistent, Isolated, and Durable).  The pager module makes sure changes
    53     53   happen all at once, that either all changes occur or none of them do,
    54     54   that two or more processes do not try to access the database
    55     55   in incompatible ways at the same time, and that once changes have been
    56     56   written they persist until explicitly deleted.  The pager also provides
    57         -an memory cache of some of the contents of the disk file.</p>
           57  +a memory cache of some of the contents of the disk file.</p>
    58     58   
    59     59   <p>The pager is unconcerned
    60     60   with the details of B-Trees, text encodings, indices, and so forth.
    61     61   From the point of view of the pager the database consists of
    62     62   a single file of uniform-sized blocks.  Each block is called a
    63     63   "page" and is usually 1024 bytes in size.   The pages are numbered
    64     64   beginning with 1.  So the first 1024 bytes of the database are called
................................................................................
   204    204   preceding rules will be repeated in bullets:
   205    205   </p>
   206    206   
   207    207   <ul>
   208    208   <li>A journal is hot if...
   209    209       <ul>
   210    210       <li>It exists, and</li>
   211         -    <li>It's master journal exists or the master journal name is an
          211  +    <li>Its master journal exists or the master journal name is an
   212    212           empty string, and</li>
   213    213       <li>There is no RESERVED lock on the corresponding database file.</li>
   214    214       </ul>
   215    215   </li>
   216    216   </ul>
   217    217   }
   218    218   

Changes to pages/optoverview.in.

   237    237     of case for latin1 characters.  Thus, by default, the following
   238    238     expression is true:
   239    239   }
   240    240   CODE {
   241    241     'a' LIKE 'A'
   242    242   }
   243    243   PARAGRAPH {
   244         -  By turned on the case_sensitive_like pragma as follows:
          244  +  By turning on the case_sensitive_like pragma as follows:
   245    245   }
   246    246   CODE {
   247    247     PRAGMA case_sensitive_like=ON;
   248    248   }
   249    249   PARAGRAPH {
   250    250     Then the LIKE operator pays attention to case and the example above would
   251    251     evaluate to false.  Note that case insensitivity only applies to
   252    252     latin1 characters - basically the upper and lower case letters of English
   253    253     in the lower 127 byte codes of ASCII.  International character sets
   254    254     are case sensitive in SQLite unless a user-supplied collating
   255    255     sequence is used.  But if you employ a user-supplied collating sequence,
   256         -  the LIKE optimization describe here will never be taken.
          256  +  the LIKE optimization described here will never be taken.
   257    257   }
   258    258   PARAGRAPH {
   259    259     The LIKE operator is case insensitive by default because this is what
   260    260     the SQL standard requires.  You can change the default behavior at
   261    261     compile time by using the -DSQLITE_CASE_SENSITIVE_LIKE command-line option
   262    262     to the compiler.
   263    263   }
................................................................................
   383    383   PARAGRAPH {
   384    384     When faced with a choice of two or more indices, SQLite tries to estimate
   385    385     the total amount of work needed to perform the query using each option.
   386    386     It then selects the option that gives the least estimated work.
   387    387   }
   388    388   PARAGRAPH {
   389    389     To help the optimizer get a more accurate estimate of the work involved
   390         -  in using various indices, the user may optional run the ANALYZE command.
          390  +  in using various indices, the user may optionally run the ANALYZE command.
   391    391     The ANALYZE command scans all indices of database where there might
   392    392     be a choice between two or more indices and gathers statistics on the
   393    393     selectiveness of those indices.  The results of this scan are stored
   394    394     in the sqlite_stat1 table.
   395    395     The contents of the sqlite_stat1 table are not updated as the database
   396    396     changes so after making significant changes it might be prudent to
   397    397     rerun ANALYZE.

Changes to pages/testing.in.

   175    175   SQLite is frequently used on embedded devices, it is important that
   176    176   SQLite be able to gracefully handle OOM errors.</p>
   177    177   
   178    178   <p>OOM testing is accomplished by simulating OOM errors.
   179    179   SQLite allows an application to substitute an alternative malloc()
   180    180   implementation using the [sqlite3_config]([SQLITE_CONFIG_MALLOC],...)
   181    181   interface.  The TCL and TH3 test harnesses are both capable of
   182         -inserting a modified version of malloc() that can be rigged fail 
          182  +inserting a modified version of malloc() that can be rigged to fail 
   183    183   after a certain number of allocations.  These instrumented mallocs
   184    184   can be set to fail only once and then start working again, or to
   185    185   continue failing after the first failure.  OOM tests are done in a
   186    186   loop.  On the first iteration of the loop, the instrumented malloc
   187    187   is rigged to fail on the first allocation.  Then some SQLite operation
   188    188   is carried out and checks are done to make sure SQLite handled the
   189    189   OOM error correctly.  Then the time-to-failure counter

Changes to req/hlr40000.txt.

   812    812   accept a "update-stmt" that conforms to the following syntax:
   813    813   <center>[syntax/update-stmt.gif]</center>
   814    814   
   815    815   HLR H46700
   816    816   In the absence of semantic or other errors, the SQLite parser shall
   817    817   accept a "update-stmt-limited" that conforms to the following syntax:
   818    818   <center>[syntax/update-stmt-limited.gif]</center>
   819         -
   820    819   HLR H46800
   821    820   In the absence of semantic or other errors, the SQLite parser shall
   822    821   accept a "qualified-table-name" that conforms to the following syntax:
   823    822   <center>[syntax/qualified-table-name.gif]</center>
   824    823   
   825    824   HLR H46900
   826    825   In the absence of semantic or other errors, the SQLite parser shall
   827    826   accept a "vacuum-stmt" that conforms to the following syntax:
   828    827   <center>[syntax/vacuum-stmt.gif]</center>