Documentation Source Text

Check-in [8f9d1225b6]
Login

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

Overview
Comment:More typo fixes.
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1: 8f9d1225b61bde1593de941c7a9f31f6291a4f9c
User & Date: drh 2011-06-20 23:51:12
Context
2011-06-21
00:17
Add a news item for the 3.7.7 release. check-in: 4bfe2f0bdf user: drh tags: trunk
2011-06-20
23:51
More typo fixes. check-in: 8f9d1225b6 user: drh tags: trunk
21:48
Documentation typos. check-in: b503d1f516 user: drh tags: trunk
Changes
Hide Diffs Side-by-Side Diffs Ignore Whitespace Patch

Changes to pages/fileio.in.

   263    263         written to the file system just before or during the failure. The exact
   264    264         combination of IO operations that SQLite is required to perform in 
   265    265         order to safely modify a database file depend on the exact 
   266    266         characteristics of the target platform.
   267    267   
   268    268       <p>
   269    269         This section describes the assumptions that SQLite makes about the
   270         -      the content of a file-system following a power or system failure. In
          270  +      content of a file-system following a power or system failure. In
   271    271         other words, it describes the extent of file and file-system corruption
   272    272         that such an event may cause.
   273    273   
   274    274       <p>
   275    275         SQLite queries an implementation for file-system characteristics
   276    276         using the xDeviceCharacteristics() and xSectorSize() methods of the
   277    277         database file file-handle. These two methods are only ever called
................................................................................
   463    463   
   464    464       ASSUMPTION A21004
   465    465         If a system failure occurs during a "delete file" operation,
   466    466         it is assumed that following system recovery the file-system will 
   467    467         either contain the file being deleted in the state it was in before
   468    468         the operation was attempted, or not contain the file at all. It is 
   469    469         assumed that it is not possible for the file to have become corrupted
   470         -      purely as a result of a failure occurfing during a "delete file" 
          470  +      purely as a result of a failure occurring during a "delete file" 
   471    471         operation.
   472    472   
   473    473       <p>
   474    474         The effects of a <b>truncate file</b> operation are not assumed to
   475    475         be made persistent until after the corresponding file has been
   476    476         <i>synced</i>.
   477    477   

Changes to pages/lang.in.

  1928   1928           the value that can be interpreted as an integer number is extracted from
  1929   1929           the TEXT value and the remainder ignored. ^Any leading spaces in the
  1930   1930           TEXT value when converting from TEXT to INTEGER are ignored. ^If there
  1931   1931           is no prefix that can be interpreted as an integer number, the result
  1932   1932           of the conversion is 0.
  1933   1933   
  1934   1934         <p>^A cast of a REAL value into an INTEGER will truncate the fractional
  1935         -      part of the REAL.  ^If an REAL is too large to be represented as an 
         1935  +      part of the REAL.  ^If a REAL is too large to be represented as an 
  1936   1936         INTEGER then the result of the cast is the largest negative integer: 
  1937   1937         -9223372036854775808.
  1938   1938   
  1939   1939   <tr>
  1940   1940     <td> NUMERIC
  1941   1941     <td> ^Casting a TEXT or BLOB value into NUMERIC first does a forced
  1942   1942      conversion into REAL but then further converts the result into INTEGER if

Changes to pages/nulls.in.

    11     11   be handled in all circumstances.
    12     12   </p>
    13     13   
    14     14   <p>
    15     15   So instead of going by the standards documents, various popular
    16     16   SQL engines were tested to see how they handle NULLs.  The idea
    17     17   was to make SQLite work like all the other engines.
    18         -A SQL test script was developed and run by volunteers on various
           18  +An SQL test script was developed and run by volunteers on various
    19     19   SQL RDBMSes and the results of those tests were used to deduce
    20     20   how each engine processed NULL values.
    21     21   The original tests were run in May of 2002.
    22     22   A copy of the test script is found at the end of this document.
    23     23   </p>
    24     24   
    25     25   <p>

Changes to pages/rtree.in.

    92     92   <em>&lt;name&gt;</em><strong>_node</strong><br>
    93     93   <em>&lt;name&gt;</em><strong>_rowid</strong><br>
    94     94   <em>&lt;name&gt;</em><strong>_parent</strong>
    95     95   </blockquote>)^
    96     96   
    97     97   <p>
    98     98   ^The shadow tables are ordinary SQLite data tables.  You can query them 
    99         -directly if you like, though this unlikely to to reveal anything particularly
           99  +directly if you like, though this unlikely to reveal anything particularly
   100    100   useful. 
   101    101   ^And you can [UPDATE], [DELETE], [INSERT] or even [DROP TABLE | DROP] 
   102    102   the shadow tables, though doing so will corrupt your R*Tree index.
   103    103   So it is best to simply ignore the shadow tables.  Recognize that they
   104    104   are there to hold your R*Tree index information and let it go as that.
   105    105   </p>
   106    106