Documentation Source Text

doc {SQLite File Format} {fileformat2.html} {
  A description of the format used for SQLite database and journal files, and
  other details required to create software to read and write SQLite 
  databases without using SQLite.
}

doc {SQLite File Format (first edition)} {fileformat.html} {
  An older and more verbose description of the SQLite file format.  
  This document provides the same information and is 
  compatible with the previous document.
}

doc {Compilation Options} {compile.html} {
  This document describes the compile time options that may be set to 
  modify the default behavior of the library or omit optional features
  in order to reduce binary size.
}

doc {Limits In SQLite} {limits.html} {

<title>File Format For SQLite Databases</title>
<tcl>hd_keywords {file format} {second edition file format document}</tcl>

<h1 align=center>
The SQLite Database File Format
</h1>

<p>This document describes and defines the on-disk database file
format used by SQLite.</p>

<p>This is the second document to define the SQLite database file format.
The [first edition file format document] differs from this one in that it is
written in a formal style whereas this document attempts to be more
conversational.  The two documents were independently written (they have
different authors) and hence serve as cross-checks for one another.
Both documents should describe exactly the same file format.  
Any incompatibilities between the two documents should be considered a bug.</p>

<h2>1.0 The Database File</h2>

<p>Most of the time the complete state of an SQLite database 
is contained a single file on disk called the "main database file".</p>

<p>While performing a transaction, SQLite stores some temporary information
in a second file called the "rollback journal".  If the application or

exclusively.  ^Newer versions of SQLite use the in-header database
size if it is available but fall back to the actual file size if
the in-header database size is not valid.</p>

<p>^The in-header database size is only considered to be valid if
it is non-zero and if the 4-byte [change counter] at offset 24
exactly matches the 4-byte [version-valid-for number] at offset 92.
^The in-header database size is always valid 
when the database is only modified using recent versions of SQLite
(versions 3.7.0 and later).
If a legacy version of SQLite writes to the database, it will not
know to update the in-header database size and so the in-header
database size could be incorrect.  But legacy versions of SQLite
will also leave the version-valid-for number at offset 92 unchanged
so it will not match the change-counter.  Hence, invalid in-header
database sizes can be detected (and ignored) by observing when
the change-counter does not match the version-valid-for number.</p>