Documentation Source Text

  Most other SQL database engines require you to dump and restore
  the database when moving from one platform to another and often
  when upgrading to a newer version of the software.
}

feature small {Compact} {
  When optimized for size, the whole SQLite library with everything enabled
  is less than 225KiB in size (as measured on an ix86 using the "size"
  is less than 275KiB in size (as measured on an ix86 using the "size"
  utility from the GNU compiler suite.)  Unneeded features can be disabled
  at compile-time to further reduce the size of the library to under
  170KiB if desired.
  190KiB if desired.
  <p>
  Most other SQL database engines are much larger than this.  IBM boasts
  that its recently released CloudScape database engine is "only" a 2MiB
  jar file - 10 times larger than SQLite even after it is compressed!
  jar file - an order of magnitude larger than SQLite even after it is
  compressed!
  Firebird boasts that its client-side library is only 350KiB.  That's
  50% larger than SQLite and does not even contain the database engine.
  The Berkeley DB library from Sleepycat is 450KiB and it omits SQL
  The Berkeley DB library from Oracle is 450KiB and it omits SQL
  support, providing the programmer with only simple key/value pairs.
}

feature typing {Manifest typing} {
  Most SQL database engines use static typing.  A datatype is associated
  with each column in a table and only values of that particular datatype
  are allowed to be stored in that column.  SQLite relaxes this restriction

failure.</p>

<p>In I/O error tests, after the I/O error simulation failure mechanism
is disabled, the database is examined using
[PRAGMA integrity_check] to make sure that the I/O error has not
introduced database corruption.</p>

<h3>3.2 Crash Testing</h3>
<h3>3.3 Crash Testing</h3>

<p>Crash testing seeks to demonstrate that an SQLite database will not
go corrupt if the application or operating system crashes or if there
is a power failure in the middle of a database update.  A separate
white-paper titled
<a href="atomiccommit.html">Atomic Commit in SQLite</a> describes the
defensive measure SQLite takes to prevent database corruption following

damage is introduced that is characteristic of the kinds of damage
one expects to see following a power loss.  Then the database is opened
and checks are made to ensure that it is well-formed and that the
transaction either ran to completion or was completely rolled back.
The interior of the loop is repeated multiple times for each
snapshot with different random damage each time.</p>

<h3>3.3 Compound failure tests</h3>
<h3>3.4 Compound failure tests</h3>

<p>The test suites for SQLite also explore the result of stacking
multiple failures.  For example, tests are run to insure correct behavior
when an I/O error or OOM fault occurs while trying to recover from a
prior crash.

<h2>4.0 Fuzz Testing</h2>