Documentation Source Text

**      privileges are dropped prior to reading any input (but after entering
**      the chroot jail, of course).  If root privileges cannot be dropped
**      (for example because the --user command-line option was omitted or
**      because the user specified by the --user option does not exist), 
**      then the process aborts with an error prior to reading any input.
**
** (3)  The length of an HTTP request is limited to MAX_CONTENT_LENGTH bytes
**      (default: 250 million).  Any HTTP request longer than this fails
**      with an error.
**
** (4)  There are hard-coded time-outs on each HTTP request.  If this process
**      waits longer than the timeout for the complete request, or for CGI
**      to finish running, then this process aborts.  (The timeout feature
**      can be disabled using the --debug command-line option.)
**

#endif
#include <assert.h>

/*
** Configure the server by setting the following macros and recompiling.
*/
#ifndef DEFAULT_PORT
#define DEFAULT_PORT "80"             /* Default TCP port for HTTP */
#endif
#ifndef MAX_CONTENT_LENGTH
#define MAX_CONTENT_LENGTH 250000000  /* Max length of HTTP request content */
#endif

/*
** We record most of the state information as global variables.  This
** saves having to pass information to subroutines as parameters, and
** makes the executable smaller...
*/

even if interrupted by system crashes or power failures.  
All of this is verified by
the automated tests using special test harnesses which simulate 
system failures.
Of course, even with all this testing, there are still bugs.
But unlike some similar projects (especially commercial competitors)
SQLite is open and honest about all bugs and provides
<a href="http://www.sqlite.org/src/rptview?rn=1">bugs lists</a> and
minute-by-minute <a href="http://www.sqlite.org/src/timeline">
chronologies</a> of code changes.</p>

<p>The SQLite code base is supported by an
<a href="crew.html">international team</a> of developers who work on
SQLite full-time.
The developers continue to expand the capabilities of SQLite
and enhance its reliability and performance while maintaining
backwards compatibility with the 
<a href="c3ref/intro.html">published interface spec</a>,
<a href="lang.html">SQL syntax</a>, and database [file format].
The source code is absolutely free to anybody who wants it,
but [professional support] is also available.</p>

<p>The SQLite project was started on 
[https://www.sqlite.org/src/timeline?c=2000-05-29+14:26:00|2000-05-09].
The future is always hard to predict, but the intent of the developers
is to support SQLite through the year 2050.  Design decisions are made
with that objective in mind.</p>

<p>We the developers hope that you find SQLite useful and we
entreat you to use it well: to make good and beautiful products that
are fast, reliable, and simple to use.  Seek forgiveness for yourself
as you forgive others.  And just as you have received SQLite for free,
so also freely give, paying the debt forward.</p>

}

Heading {Precompiled Binaries for Windows} win32

set start $nDownload

Product YEAR/sqlite-dll-win32-x86-VVV.zip {
  32-bit DLL (x86) for SQLite version VERSION.
}

Product YEAR/sqlite-dll-win64-x64-VVV.zip {
  64-bit DLL (x64) for SQLite version VERSION.
}

Product YEAR/sqlite-tools-win32-x86-VVV.zip {

<title>sqldiff.exe: Database Difference Utility</title>
<tcl>hd_keywords sqldiff sqldiff.exe</tcl>

<table_of_contents>
<h1>Usage</h1>

<p>
The <tt>sqldiff.exe</tt> binary is a command-line utility program that
displays the differences between SQLite databases.  Example
usage:

<codeblock>
sqldiff &#91;options&#93; database1.sqlite database2.sqlite
</codeblock>

<p>
The usual output is an SQL script that will transform
database1.sqlite (the "source" database) into database2.sqlite
(the "destination" database).  This behavior can be
altered using command-line switches:

<dl>
<dt><b>--changeset FILE</b></dt>
<dd><p>Do not write changes to standard output.  Instead, write a (binary)

<dd><p>Show how many rows have changed on each table, but do not show
       the actual chagnes</dd>
<dt><b>--table TABLE</b></dt>
<dd><p>Show only the differences in content for TABLE, not for the
       entire database</p></dd>
<dt><b>--transaction</b></dt>
<dd><p>Wrap SQL output in a single large transaction</p></dd>
<dt><b>--vtab</b></dt>
<dd><p>Add support for handling [FTS3], [FTS5] and [rtree] virtual tables. 
       <a href=#vtab>See below</a> for details. 
</p></dd>
</dl>

<h1>How It Works</h1>

<p>The sqldiff.exe utility works by finding rows in the source and
destination that are logical "pairs".  The default behavior is to
treat two rows as pairs if they are in tables with the same name
and they have the same [rowid], or in the case of a [WITHOUT ROWID]
table if they have the same [PRIMARY KEY].  Any differences in the
content of paired rows are output as UPDATEs.  Rows in the source
database that could not be paired are output as DELETEs.  Rows in
the destination database that could not be paired are output as
INSERTs.

<p>The --primarykey flag changes the pairing algorithm slightly so
that the schema-declared [PRIMARY KEY] is always used for pairing,
even on tables that have a [rowid].  This is often a better choice
for finding differences, however it can lead to missed differences in
the case of rows that have one or more PRIMARY KEY columns set to
NULL.</p>

<h1>Limitations</h1>

<ol>
<li>
<p>The sqldiff.exe utility is unable to compute differences for
rowid tables for which the rowid is inaccessible.  An example of
a table with an inaccessible rowid is:

<codeblock>
CREATE TABLE inaccessible_rowid(
   "rowid" TEXT,
   "oid" TEXT,
   "_rowid_" TEXT
);
</codeblock>

<li><p>
The sqldiff.exe utility does not (currently) display differences in
[CREATE TRIGGER|TRIGGERs] or [CREATE VIEW|VIEWs].

<li><p id=vtab>
By default, differences in the schema or content of virtual tables are
not reported on. 

<p>However, if a [virtual table] implementation creates real tables (sometimes
refered to as "shadow" tables) within the database to store its data in, then
sqldiff.exe does calculate the difference between these. This can have
surprising effects if the resulting SQL script is then run on a database that
is not <i>exactly</i> the same as the source database. For several of SQLite's
bundled virtual tables (FTS3, FTS5, rtree and others), the surprising effects
may include corruption of the virtual table content.

<p> If the --vtab option is passed to sqldiff.exe, then it ignores all 
underlying shadow tables belonging to an FTS3, FTS5 or rtree virtual table
and instead includes the virtual table differences directly.

</ol>