Documentation Source Text

  <li> [sqlite3_column_table_name16()] </li>
  <li> [sqlite3_column_origin_name()] </li>
  <li> [sqlite3_column_origin_name16()] </li>
  </ul>
}

COMPILE_OPTION {SQLITE_ENABLE_DBPAGE_VTAB} {
  This option enables the 
  [https://sqlite.org/src/file/src/dbpage.c|sqlite_dbpage virtual table].
}

COMPILE_OPTION {SQLITE_ENABLE_DBSTAT_VTAB} {
  This option enables the [dbstat virtual table].
}

COMPILE_OPTION {SQLITE_ENABLE_DESERIALIZE} {

  <li> [sqlite3_column_table_name16()] </li>
  <li> [sqlite3_column_origin_name()] </li>
  <li> [sqlite3_column_origin_name16()] </li>
  </ul>
}

COMPILE_OPTION {SQLITE_ENABLE_DBPAGE_VTAB} {
  This option enables the [SQLITE_DBPAGE virtual table].

}

COMPILE_OPTION {SQLITE_ENABLE_DBSTAT_VTAB} {
  This option enables the [dbstat virtual table].
}

COMPILE_OPTION {SQLITE_ENABLE_DESERIALIZE} {

<title>The SQLITE_DBPAGE Virtual Table</title>
<tcl>hd_keywords sqlite_dbpage {SQLITE_DBPAGE virtual table} \
        {the SQLITE_DBPAGE extension}</tcl>
<fancy_format>

<h1>Overview</h1>

<p>
The SQLITE_DBPAGE extension implements an [eponymous-only virtual table] that
provides direct access to the underlying database file by interacting directly
with the page.  SQLITE_DBPAGE is capable of both reading and writing any
page of the database.  Because interaction is through the pager layer, all
changes are transactional.
</p>

<p>
<b>Warning:</b> writing to the SQLITE_DBPAGE virtual table can very easily
cause unrecoverably database corruption.  Do not allow untrusted components
to access the SQLITE_DBPAGE table.  Use appropriate care while using the
SQLITE_DBPAGE table.  Back up important data prior to experimenting with the
SQLITE_DBPAGE table.

<p>
The SQLITE_DBPAGE extension is included in the [amalgamation] though 
it is disabled
by default.  Use the [SQLITE_ENABLE_DBPAGE_VTAB] compile-time option to enable
the SQLITE_DBPAGE extension.  The SQLITE_DBPAGE extension makes use of
unpublished internal interfaces and is not run-time loadable.  The only way
to add SQLITE_DBPAGE to an application is to compile it in using the
[SQLITE_ENABLE_DBPAGE_VTAB] compile-time option.
</p>

<p>
The SQLITE_DBPAGE extension is enabled in default builds
of the [command-line shell].

<h1>Usage</h1>

<p>
The SQLITE_DBPAGE virtual table read/write table that provides direct
access to the underlying disk file on a page-by-page basis.  The
virtual table appears to have a schema like this:

<codeblock>
CREATE TABLE sqlite_dbpage(
  pgno INTEGER PRIMARY KEY,
  data BLOB
);
</codeblock>

<p>
An SQLite database file is divided into pages.
The first page is 1, the second page is 2, and so forth.
There is no page 0.
Every page is the same size.
The size of every page is a power of 2 between 512 and 65536.
See the [file format] documentation for further details.

<p>
The SQLITE_DBPAGE table allows an application to view or replace the
raw binary content of each page of the database file.
No attempt is made to interpret the content of the page.
Content is returned byte-for-byte as it appears on disk.

<p>
The SQLITE_DBPAGE table has one row for each page in the database file.
SQLITE_DBPAGE allows pages to be read or to be overwritten.
However the size of the database file cannot be changed.  It is not
possible to change the number of rows in the SQLITE_DBPAGE table by
running DELETE or INSERT operations against that table.

<h2>Using SQLITE_DBPAGE On ATTACH-ed Databases</h2>

<p>
The SQLITE_DBPAGE table schema shown above is incomplete.  There is
a third [hidden column] named "schema" that determines which
[ATTACH|ATTACH-ed database] should be read or written.  Because
the "schema" column is hidden, it can be used as a parameter when
SQLITE_DBPAGE is invoked as a [table-valued function].

<p>
For example, suppose an additional database is attached to the 
database connection using a statement like this:

<codeblock>
ATTACH 'auxdata1.db' AS aux1;
</codeblock>

<p>
Then to read the first page of that database file, one merely runs:

<codeblock>
SELECT data FROM sqlite_dbpage('aux1') WHERE pgno=1;
</codeblock>

<p>
If the "schema" is omitted, it defaults to the primary database
(usually called 'main', unless renamed using [SQLITE_DBCONFIG_MAINDBNAME]).
Hence, the following two queries are normally equivalent:

<codeblock>
SELECT data FROM sqlite_dbpage('main') WHERE pgno=1;
SELECT data FROM sqlite_dbpage WHERE pgno=1;
</codeblock>

<p>
The SQLITE_DBPAGE table can participate in a join just like any other
table.  Hence, to see the content of the first page to all connected
database files, one might run a statement like this:

<codeblock>
SELECT dbpage.data, dblist.name
  FROM pragma_database_list AS dblist
  JOIN sqlite_dbpage(dblist.name) AS dbpage
 WHERE dbpage.pgno=1;
</codeblock>

<tcl>
unset -nocomplain vtab
set vtab(sqlite_dbpage) {
  ifdef      SQLITE_ENABLE_DBPAGE_VTAB
  type       eponymous
  rw         1
  src        src/dbpage.c
  doc        {}
  supported  1
  synopsis   {
    Key/value store for the raw database file content.  The key is the
    page number and the value is binary page content.
  }
}
set vtab(dbstat) {

<tcl>
unset -nocomplain vtab
set vtab(sqlite_dbpage) {
  ifdef      SQLITE_ENABLE_DBPAGE_VTAB
  type       eponymous
  rw         1
  src        src/dbpage.c
  doc        *sqlite_dbpage
  supported  1
  synopsis   {
    Key/value store for the raw database file content.  The key is the
    page number and the value is binary page content.
  }
}
set vtab(dbstat) {