Documentation Source Text

  that employ the BETWEEN operator.
}

COMPILE_OPTION {SQLITE_OMIT_BLOB_LITERAL} {
  When this option is defined, it is not possible to specify a blob in
  an SQL statement using the X'ABCD' syntax.
}







COMPILE_OPTION {SQLITE_OMIT_BUILTIN_TEST} {
  A standard SQLite build includes a small amount of logic controlled
  by the [sqlite3_test_control()] interface that is used to exercise
  parts of the SQLite core that are difficult to control and measure using
  the standard API.  This option omits that built-in test logic.
}
................................................................................

COMPILE_OPTION {SQLITE_OMIT_CHECK} {
  This option causes SQLite to omit support for CHECK constraints.
  The parser will still accept CHECK constraints in SQL statements,
  they will just not be enforced.
}

COMPILE_OPTION {SQLITE_OMIT_COMPLETE} {
  This option causes the [sqlite3_complete()] and [sqlite3_complete16()]
  interfaces to be omitted.
}

COMPILE_OPTION {SQLITE_OMIT_COMPILEOPTION_DIAGS} {
  This option is used to omit the compile-time option diagnostics available
  in SQLite, including the [sqlite3_compileoption_used()] and
  [sqlite3_compileoption_get()] C/C++ functions, the
  [sqlite_compileoption_used()] and [sqlite_compileoption_get()] SQL functions,
  and the [compile_options pragma].
}






COMPILE_OPTION {SQLITE_OMIT_COMPOUND_SELECT} {
  This option is used to omit the compound [SELECT] functionality. 
  [SELECT] statements that use the 
  UNION, UNION ALL, INTERSECT or EXCEPT compound SELECT operators will 
  cause a parse error.
}
................................................................................
  [sqlite3_global_recover()],
  [sqlite3_thread_cleanup()] and
  [sqlite3_memory_alarm()] interfaces.
}

COMPILE_OPTION {SQLITE_OMIT_DISKIO} {
  This option omits all support for writing to the disk and forces
  databases to exist in memory only.

}

COMPILE_OPTION {SQLITE_OMIT_EXPLAIN} {
  Defining this option causes the [EXPLAIN] command to be omitted from the
  library. Attempting to execute an [EXPLAIN] statement will cause a parse
  error.
}
................................................................................

COMPILE_OPTION {SQLITE_OMIT_LOCALTIME} {
  This option omits the "localtime" modifier from the date and time
  functions.  This option is sometimes useful when trying to compile
  the date and time functions on a platform that does not support the
  concept of local time.
}





COMPILE_OPTION {SQLITE_OMIT_MEMORYDB} {
  When this is defined, the library does not respect the special database
  name ":memory:" (normally used to create an [in-memory database]). If 
  ":memory:" is passed to [sqlite3_open()], [sqlite3_open16()], or
  [sqlite3_open_v2()], a file with this name will be 
  opened or created.
................................................................................
  for which the schema contains VIEW objects. 
}

COMPILE_OPTION {SQLITE_OMIT_VIRTUALTABLE} {
  This option omits support for the [sqlite3_vtab | Virtual Table]
  mechanism in SQLite.
}





COMPILE_OPTION {SQLITE_OMIT_WSD} {
  This options builds a version of the SQLite library that contains no
  Writable Static Data (WSD).  WSD is global variables and/or static
  variables.  Some platforms do not support WSD, and this option is necessary
  in order for SQLite to work those platforms.  

  that employ the BETWEEN operator.
}

COMPILE_OPTION {SQLITE_OMIT_BLOB_LITERAL} {
  When this option is defined, it is not possible to specify a blob in
  an SQL statement using the X'ABCD' syntax.
}

COMPILE_OPTION {SQLITE_OMIT_BTREECOUNT} {
  When this option is defined, an optimization that accelerates counting
  all entires in a table (in other words, an optimization that helps
  "SELECT count(*) FROM table" run faster) is omitted.
}

COMPILE_OPTION {SQLITE_OMIT_BUILTIN_TEST} {
  A standard SQLite build includes a small amount of logic controlled
  by the [sqlite3_test_control()] interface that is used to exercise
  parts of the SQLite core that are difficult to control and measure using
  the standard API.  This option omits that built-in test logic.
}
................................................................................

COMPILE_OPTION {SQLITE_OMIT_CHECK} {
  This option causes SQLite to omit support for CHECK constraints.
  The parser will still accept CHECK constraints in SQL statements,
  they will just not be enforced.
}






COMPILE_OPTION {SQLITE_OMIT_COMPILEOPTION_DIAGS} {
  This option is used to omit the compile-time option diagnostics available
  in SQLite, including the [sqlite3_compileoption_used()] and
  [sqlite3_compileoption_get()] C/C++ functions, the
  [sqlite_compileoption_used()] and [sqlite_compileoption_get()] SQL functions,
  and the [compile_options pragma].
}

COMPILE_OPTION {SQLITE_OMIT_COMPLETE} {
  This option causes the [sqlite3_complete()] and [sqlite3_complete16()]
  interfaces to be omitted.
}

COMPILE_OPTION {SQLITE_OMIT_COMPOUND_SELECT} {
  This option is used to omit the compound [SELECT] functionality. 
  [SELECT] statements that use the 
  UNION, UNION ALL, INTERSECT or EXCEPT compound SELECT operators will 
  cause a parse error.
}
................................................................................
  [sqlite3_global_recover()],
  [sqlite3_thread_cleanup()] and
  [sqlite3_memory_alarm()] interfaces.
}

COMPILE_OPTION {SQLITE_OMIT_DISKIO} {
  This option omits all support for writing to the disk and forces
  databases to exist in memory only.  This option has not been 
  maintained and probably does not work with newer versions of SQLite.
}

COMPILE_OPTION {SQLITE_OMIT_EXPLAIN} {
  Defining this option causes the [EXPLAIN] command to be omitted from the
  library. Attempting to execute an [EXPLAIN] statement will cause a parse
  error.
}
................................................................................

COMPILE_OPTION {SQLITE_OMIT_LOCALTIME} {
  This option omits the "localtime" modifier from the date and time
  functions.  This option is sometimes useful when trying to compile
  the date and time functions on a platform that does not support the
  concept of local time.
}

COMPILE_OPTION {SQLITE_OMIT_LOOKASIDE} {
  This option omits the [lookaside memory allocator].
}

COMPILE_OPTION {SQLITE_OMIT_MEMORYDB} {
  When this is defined, the library does not respect the special database
  name ":memory:" (normally used to create an [in-memory database]). If 
  ":memory:" is passed to [sqlite3_open()], [sqlite3_open16()], or
  [sqlite3_open_v2()], a file with this name will be 
  opened or created.
................................................................................
  for which the schema contains VIEW objects. 
}

COMPILE_OPTION {SQLITE_OMIT_VIRTUALTABLE} {
  This option omits support for the [sqlite3_vtab | Virtual Table]
  mechanism in SQLite.
}

COMPILE_OPTION {SQLITE_OMIT_WAL} {
  This option omits the "[write-ahead log]" (a.k.a. "[WAL]") capability.
}

COMPILE_OPTION {SQLITE_OMIT_WSD} {
  This options builds a version of the SQLite library that contains no
  Writable Static Data (WSD).  WSD is global variables and/or static
  variables.  Some platforms do not support WSD, and this option is necessary
  in order for SQLite to work those platforms.  

    (<a href="omitted.html">Features not supported</a>)</li>
<li>A complete database is stored in a 
    <a href="onefile.html">single cross-platform disk file</a>.</li>
<li>Supports terabyte-sized databases and gigabyte-sized strings
    and blobs.  (See <a href="limits.html">limits.html</a>.)
<li>Small code footprint: 
    <a href="http://www.sqlite.org/cvstrac/wiki?p=SizeOfSqlite">
    less than 300KiB</a> fully configured or less
    than 180KiB with optional features omitted.</li>
<li><a href="speed.html">Faster</a> than popular client/server database
    engines for most common operations.</li>
<li>Simple, easy to use <a href="c3ref/intro.html">API</a>.</li>
<li>Written in ANSI-C.  <a href="tclsqlite.html">TCL bindings</a> included.
    Bindings for dozens of other languages 
    <a href="http://www.sqlite.org/cvstrac/wiki?p=SqliteWrappers">
    available separately.</a></li>

    (<a href="omitted.html">Features not supported</a>)</li>
<li>A complete database is stored in a 
    <a href="onefile.html">single cross-platform disk file</a>.</li>
<li>Supports terabyte-sized databases and gigabyte-sized strings
    and blobs.  (See <a href="limits.html">limits.html</a>.)
<li>Small code footprint: 
    <a href="http://www.sqlite.org/cvstrac/wiki?p=SizeOfSqlite">
    less than 325KiB</a> fully configured or less
    than 190KiB with optional features omitted.</li>
<li><a href="speed.html">Faster</a> than popular client/server database
    engines for most common operations.</li>
<li>Simple, easy to use <a href="c3ref/intro.html">API</a>.</li>
<li>Written in ANSI-C.  <a href="tclsqlite.html">TCL bindings</a> included.
    Bindings for dozens of other languages 
    <a href="http://www.sqlite.org/cvstrac/wiki?p=SqliteWrappers">
    available separately.</a></li>

magic number in the first 4 bytes of the WAL header is 0x377f0683 and
the integers are little-endian the magic number is 0x377f0682.
The checksum values are always stored in the frame header in a
big-endian format regardless of which byte order is used to compute
the checksum.</p>

<p>The checksum algorithm only works for content which is a multiple of
8 bytes in length.  In other words, if the puts are x(0) through x(N)
then N must be odd.
The checksum algorithm is as follows:

<blockquote><pre> 
s0 = s1 = 0
for i from 0 to n-1 step 2:
   s0 += x(i) + s1;
................................................................................
frame or are followed by a commit frame, then page P is read from
the database file.</p>

<p>To start a read transaction, the reader records the index of the last
valid frame in the WAL.  The reader uses this recorded "mxFrame" value
for all subsequent read operations.  New transactions can be appended
to the WAL, but as long as the reader uses its original mxFrame value
and ignores the newly appended content, it will see a consistent snapshot
of the database from a single point in time.  This technique allows
multiple concurrent readers to view different versions of the database
content simultaneously.</p>

<p>The reader algorithm in the previous paragraphs works correctly, but 
because frames for page P can appear anywhere within the WAL, the
reader has to scan the entire WAL looking for page P frames.  If the
WAL is large (multiple megabytes is typical) that scan can be slow,
and read performance suffers.  To overcome this problem, a separate
data structure called the wal-index is maintained to expedite the
search for frames of a particular page.</p>

<tcl>hd_fragment walindexformat {WAL-index format}</tcl>
<h3>4.5 WAL-Index Format</h3>

<p>Conceptually, the wal-index is shared memory, though the current
VFS implementations use a mmapped file for the wal-index.  Because


the wal-index is shared memory, SQLite does not support 
[PRAGMA journal_mode | journal_mode=WAL] 
on a network filesystem when clients are on different machines.
All users of the database must be able to share the same memory.</p>

<p>The purpose of the wal-index is to answer this question quickly:</p>

<blockquote><i>
Given a page number P and a maximum WAL frame index M,
return the largest WAL frame index for page P that does not exceed M, 
or return NULL if there are no frames for page P that do not exceed M.
</i></blockquote>






<p>The wal-index is transient.  After a crash, the wal-index is
reconstructed from the original WAL file.  The VFS is required
to either truncate or zero the header of the wal-index when the last
connection to it closes.  Because the wal-index is transient, it can
use an architecture-specific format; it does not have to be cross-platform.
Hence, unlike the database and WAL file formats which store all values

magic number in the first 4 bytes of the WAL header is 0x377f0683 and
the integers are little-endian the magic number is 0x377f0682.
The checksum values are always stored in the frame header in a
big-endian format regardless of which byte order is used to compute
the checksum.</p>

<p>The checksum algorithm only works for content which is a multiple of
8 bytes in length.  In other words, if the inputs are x(0) through x(N)
then N must be odd.
The checksum algorithm is as follows:

<blockquote><pre> 
s0 = s1 = 0
for i from 0 to n-1 step 2:
   s0 += x(i) + s1;
................................................................................
frame or are followed by a commit frame, then page P is read from
the database file.</p>

<p>To start a read transaction, the reader records the index of the last
valid frame in the WAL.  The reader uses this recorded "mxFrame" value
for all subsequent read operations.  New transactions can be appended
to the WAL, but as long as the reader uses its original mxFrame value
and ignores subsequently appended content, the reader will see a 
consistent snapshot of the database from a single point in time.  
This technique allows multiple concurrent readers to view different 
versions of the database content simultaneously.</p>

<p>The reader algorithm in the previous paragraphs works correctly, but 
because frames for page P can appear anywhere within the WAL, the
reader has to scan the entire WAL looking for page P frames.  If the
WAL is large (multiple megabytes is typical) that scan can be slow,
and read performance suffers.  To overcome this problem, a separate
data structure called the wal-index is maintained to expedite the
search for frames of a particular page.</p>

<tcl>hd_fragment walindexformat {WAL-index format}</tcl>
<h3>4.5 WAL-Index Format</h3>

<p>Conceptually, the wal-index is shared memory, though the current
VFS implementations use a mmapped file for the wal-index.  The mmapped
file is in the same directory as the database and has the same name
as the database with a "<tt>-shm</tt>" suffix appended.  Because
the wal-index is shared memory, SQLite does not support 
[PRAGMA journal_mode | journal_mode=WAL] 
on a network filesystem when clients are on different machines.
All users of the database must be able to share the same memory.</p>

<p>The purpose of the wal-index is to answer this question quickly:</p>

<blockquote><i>
Given a page number P and a maximum WAL frame index M,
return the largest WAL frame index for page P that does not exceed M, 
or return NULL if there are no frames for page P that do not exceed M.
</i></blockquote>

<p>The <i>M</i> value in the previous paragraph is the "mxFrame" value
defined in [WAL read algorithm | section 4.4] that is read at the start 
of a transaction and which defines the maximum frame from the WAL that 
the reader will use.</p>

<p>The wal-index is transient.  After a crash, the wal-index is
reconstructed from the original WAL file.  The VFS is required
to either truncate or zero the header of the wal-index when the last
connection to it closes.  Because the wal-index is transient, it can
use an architecture-specific format; it does not have to be cross-platform.
Hence, unlike the database and WAL file formats which store all values