Documentation Source Text

Check-in [7a37431be5]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Typo fixes.
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA3-256: 7a37431be558f59a8226032fa537d070e1b90e43f2d979f4aae71c79ae5cf830
User & Date: drh 2019-09-28 19:02:24
Context
2019-10-02
10:40
Typos and minor enhancements to the althttpd.md document. check-in: 5140eb346c user: drh tags: trunk
2019-09-28
19:02
Typo fixes. check-in: 7a37431be5 user: drh tags: trunk
2019-09-27
17:55
Updates so that documentation agrees with requirement marks. check-in: f1a1831162 user: drh tags: trunk
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to pages/books.in.

25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
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.







|







25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
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.

Changes to pages/compile.in.

1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
....
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
}

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,







|







 







|







1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
....
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
}

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,

Changes to pages/lang.in.

5244
5245
5246
5247
5248
5249
5250
5251
5252
5253
5254
5255
5256
5257
5258
     [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>







|







5244
5245
5246
5247
5248
5249
5250
5251
5252
5253
5254
5255
5256
5257
5258
     [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>

Changes to pages/security.in.

136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
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.







|







136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
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.

Changes to pages/vtablist.in.

10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
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







|







10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
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