Documentation Source Text

               sequence of bytes is:
                 <pre>0xd9 0xd5 0x05 0xf9 0x20 0xa1 0x63 0xd7</pre>
    </table>

[h3 "Master-Journal File Details" masterjournal_file_format]

[h2 "Reading an SQLite Database" reading_from_files]


















































[h2 "Writing to an SQLite Database" writing_to_files]

  <p>
    When an SQLite user commits a transaction that modifies the contents
    of the database, the database representation on disk must be modified
    to reflect the new contents of the database. SQLite is required to do

               sequence of bytes is:
                 <pre>0xd9 0xd5 0x05 0xf9 0x20 0xa1 0x63 0xd7</pre>
    </table>

[h3 "Master-Journal File Details" masterjournal_file_format]

[h2 "Reading an SQLite Database" reading_from_files]

  <p>
    As described in section <cite>pages_and_page_types</cite> of this document,
    an SQLite database image is a set of contiguously numbered fixed size 
    pages. The numbering starts at 1, not 0. Page 1 contains the 
    <i>database file header</i> and the root page of the <i>schema table</i>, 
    and all other pages within the database image are somehow referred to 
    by number from page 1, either directly or indirectly.
    
  <p>
    Usually, the <i>database file</i> contains the complete, unadulterated 
    <i>database image</i>. When this is the case, the file offset of each 
    database page can be calculated based on its page number. Reading the
    contents of a <i>database page</i> is a simple matter of reading a
    block of <i>page-size</i> bytes from the calculated offset. However, if 
    there is a <i>journal file</i> corresponding to the <i>database file</i>
    present within the file-system then the situation can be more 
    complicated. The current data for each page of the <i>database image</i>
    may currently be stored within the <i>database file</i> at a file offset
    based on its page number as it normally is, or the current version of
    the data may be stored somewhere within the <i>journal file</i>.

  <ol>
    <li> <p>If the <i>journal file</i> contains a well-formed 
      <i>master-journal pointer</i>, and the <i>master-journal</i> is either
      not present in the file-system or it does not contain the name of
      the <i>journal file</i>, then the contents of the <i>journal file</i>
      are invalid. The <i>database file</i> contains the database image
      verbatim.

    <li> <p>If the first 28 bytes of the <i>journal file</i> do not contain
      a well-formed <i>journal header</i>, or they contain a well-formed
      <i>journal header</i> with the <i>record count</i> field set to zero,
      then the contents of the <i>journal file</i> are invalid. As in case
      1 above, the <i>database file</i> contains the database image verbatim.




      <li> <p>If the first 28 bytes of the <i>journal file</i> contain a
      well-formed <i>journal header</i> with a non-zero value for the <i>record
      count</i> field, then the <i>page-size</i> used by the <i>database
      image</i> is as stored at byte offset 24 of the <i>journal header</i>.
      The size of the database image in pages is as stored at byte offset 16 of
      the <i>journal header</i>.


  </ol>


[h2 "Writing to an SQLite Database" writing_to_files]

  <p>
    When an SQLite user commits a transaction that modifies the contents
    of the database, the database representation on disk must be modified
    to reflect the new contents of the database. SQLite is required to do