Documentation Source Text

book fully explains the format of the SQLite database file. It shows how
records are encoded, how to decode them manually and how to decode
records that are partially overwritten. It also describe how the
workings of SQLite, and in particular the journal and WAL, can be used
to ascertain what has happened in a manner that cannot be determined
from the data alone. The book covers basic SQL queries and how they can
be used to create a custom report that includes data from different
tables, and shows how one can use SQL queries to test hypothesises about
the relationships of data in different tables. 
<p>
This book is aimed mainly at
forensic practitioners, and it is assumed that the reader has some basic
knowledge of computer forensics; it will also be of interest to computer
professionals in general particularly those who have an interest in the
SQLite file format.

book fully explains the format of the SQLite database file. It shows how
records are encoded, how to decode them manually and how to decode
records that are partially overwritten. It also describe how the
workings of SQLite, and in particular the journal and WAL, can be used
to ascertain what has happened in a manner that cannot be determined
from the data alone. The book covers basic SQL queries and how they can
be used to create a custom report that includes data from different
tables, and shows how one can use SQL queries to test hypotheses about
the relationships of data in different tables. 
<p>
This book is aimed mainly at
forensic practitioners, and it is assumed that the reader has some basic
knowledge of computer forensics; it will also be of interest to computer
professionals in general particularly those who have an interest in the
SQLite file format.

}

COMPILE_OPTION {SQLITE_HAVE_ZLIB} {
  This option causes some extensions to link against the 
  [https://zlib.net|zlib compression library].
  <p>
  This option has no affect on the SQLite core.  It is only used by extensions.
  This is option is necessary for the commpression and decompression
  functions that are part of [SQL Archive] support in the
  [command-line shell].
  <p>
  When compiling with this option, it will normally
  be necessary to add a linker option to include the zlib library in the
  build.  Normal this option is "-lz" but might be different on different
  systems.
................................................................................
interface linkage for certain kinds of SQLite builds.  The Makefiles will normally
handle setting these macros automatically.  Application developers should
not need to worry with these macros.  The following documentation about these 
macros is included completeness.</p>

<tcl>
COMPILE_OPTION {SQLITE_API} {
  This macro identifies a externally visible interface for SQLite.
  This macro is sometimes set to "extern".  But the definition is
  compiler-specific.
}

COMPILE_OPTION {SQLITE_APICALL} {
  This macro identifies the calling convention used by public interface
  routines in SQLite.  This macro is normally defined to be nothing,

}

COMPILE_OPTION {SQLITE_HAVE_ZLIB} {
  This option causes some extensions to link against the 
  [https://zlib.net|zlib compression library].
  <p>
  This option has no affect on the SQLite core.  It is only used by extensions.
  This is option is necessary for the compression and decompression
  functions that are part of [SQL Archive] support in the
  [command-line shell].
  <p>
  When compiling with this option, it will normally
  be necessary to add a linker option to include the zlib library in the
  build.  Normal this option is "-lz" but might be different on different
  systems.
................................................................................
interface linkage for certain kinds of SQLite builds.  The Makefiles will normally
handle setting these macros automatically.  Application developers should
not need to worry with these macros.  The following documentation about these 
macros is included completeness.</p>

<tcl>
COMPILE_OPTION {SQLITE_API} {
  This macro identifies an externally visible interface for SQLite.
  This macro is sometimes set to "extern".  But the definition is
  compiler-specific.
}

COMPILE_OPTION {SQLITE_APICALL} {
  This macro identifies the calling convention used by public interface
  routines in SQLite.  This macro is normally defined to be nothing,

     [SQLITE_OPEN_URI] flag.
</ul>

<p>
The VACUUM INTO command is transactional in the sense that
the generated output database is a consistent snapshot of the
original database.  However, if the VACUUM INTO command is
interrupted by a unplanned shutdown or power lose, then
the generated output database might be incomplete and corrupt.
Also, SQLite does not invoke fsync() or FlushFileBuffers()
on the generated database to ensure that it has reached
non-volatile storage before completing.


<tcl>hd_fragment howvacuumworks {how vacuum works}</tcl>

     [SQLITE_OPEN_URI] flag.
</ul>

<p>
The VACUUM INTO command is transactional in the sense that
the generated output database is a consistent snapshot of the
original database.  However, if the VACUUM INTO command is
interrupted by an unplanned shutdown or power lose, then
the generated output database might be incomplete and corrupt.
Also, SQLite does not invoke fsync() or FlushFileBuffers()
on the generated database to ensure that it has reached
non-volatile storage before completing.


<tcl>hd_fragment howvacuumworks {how vacuum works}</tcl>

and that no existing ordinary tables have been replaced by
malicious views.
</p>
<li><p>
If the application uses [application-defined SQL functions] that have
side effects, then it is recommended to set the [SQLITE_DIRECTONLY] flag
on those SQL functions to prevent them from being used inside triggers
and views.  To illustrate the importants of this flag, consider an
application that implements an SQL function "send_money(...)".  Without
the SQLITE_DIRECTONLY flag, an attacker might be able to add a trigger
or view that uses that custom function, then trick a
high-privilege application to run an otherwise harmless query that invokes
that malicious trigger or view.  The SQLITE_DIRECTONLY flag prevents the
attack by requiring the "send_money()" function to be invoked directly
by the application, rather than indirectly through a trigger or view.

and that no existing ordinary tables have been replaced by
malicious views.
</p>
<li><p>
If the application uses [application-defined SQL functions] that have
side effects, then it is recommended to set the [SQLITE_DIRECTONLY] flag
on those SQL functions to prevent them from being used inside triggers
and views.  To illustrate the importance of this flag, consider an
application that implements an SQL function "send_money(...)".  Without
the SQLITE_DIRECTONLY flag, an attacker might be able to add a trigger
or view that uses that custom function, then trick a
high-privilege application to run an otherwise harmless query that invokes
that malicious trigger or view.  The SQLITE_DIRECTONLY flag prevents the
attack by requiring the "send_money()" function to be invoked directly
by the application, rather than indirectly through a trigger or view.

interface but which is not stored in the database file, at least
not directly.  The virtual table mechanism is a feature
of SQLite that allows SQLite to access and manipulate resources
other than bits in the database file using the powerful SQL
query language.

<p>
The table below lists a few of the virtual tables implmentations
available for SQLite.  Developers can deploy these virtual tables
in their own applications, or use the implementations shown below
as templates for writing their own virtual tables.

<p>
The list below is not exhaustive.
Other virtual table implementation exist in the SQLite source tree

interface but which is not stored in the database file, at least
not directly.  The virtual table mechanism is a feature
of SQLite that allows SQLite to access and manipulate resources
other than bits in the database file using the powerful SQL
query language.

<p>
The table below lists a few of the virtual tables implementations
available for SQLite.  Developers can deploy these virtual tables
in their own applications, or use the implementations shown below
as templates for writing their own virtual tables.

<p>
The list below is not exhaustive.
Other virtual table implementation exist in the SQLite source tree