Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Overview
Comment: | Typo fixes. |
---|---|
Downloads: | Tarball | ZIP archive |
Timelines: | family | ancestors | descendants | both | trunk |
Files: | files | file ages | folders |
SHA3-256: |
7a37431be558f59a8226032fa537d070 |
User & Date: | drh 2019-09-28 19:02:24.884 |
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
Changes to pages/books.in.
︙ | ︙ | |||
25 26 27 28 29 30 31 | 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 | | | 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 | } 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. | | | 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 | } 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. |
︙ | ︙ | |||
1905 1906 1907 1908 1909 1910 1911 | 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} { | | | 1905 1906 1907 1908 1909 1910 1911 1912 1913 1914 1915 1916 1917 1918 1919 | 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 | [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 | | | 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 | 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 | | | 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 | 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> | | | 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 |
︙ | ︙ |