Documentation Source Text

Check-in [8283dbcef9]
Login

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

Overview
Comment:Fix documentation typos reported on the mailing list by Philip Newton.
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | branch-3.21
Files: files | file ages | folders
SHA3-256:8283dbcef99f668b616560b45fb732643ff64ca3286e15f73f6669970d0a1ecc
User & Date: drh 2017-11-09 21:01:23
Context
2017-11-23
21:43
Default value for the "s" query parameter in /search is now "d". check-in: 6182e9ea42 user: drh tags: branch-3.21
2017-11-09
21:01
Fix documentation typos reported on the mailing list by Philip Newton. check-in: 8283dbcef9 user: drh tags: branch-3.21
2017-11-05
22:22
On the JSON1 documentation, make sure all arguments in the Overview section are italicized. check-in: 0d9fba9226 user: drh tags: branch-3.21
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to pages/inmemorydb.in.

114
115
116
117
118
119
120
121

122
123
124
125
126
127
128
129
130
131
<p>A different temporary file is created each time, so that just like as
with the special ":memory:" string, two database connections to temporary
databases each have their own private database.  Temporary databases are
automatically deleted when the connection that created them closes.</p>

<p>Even though a disk file is allocated for each temporary database, in
practice the temporary database usually resides in the in-memory pager
cache and hence is very little difference between a pure in-memory database

created by ":memory:" and a temporary database created by an empty filename.
The sole difference is that a ":memory:" database must remain in memory
at all times whereas parts of a temporary database might be flushed to
disk if database becomes large or if SQLite comes under memory pressure.</p>

<p>The previous paragraphs describe the behavior of temporary databases
under the default SQLite configuration.  An application can use the
[temp_store pragma] and the [SQLITE_TEMP_STORE] compile-time parameter to
force temporary databases to behave as pure in-memory databases, if desired.
</p>







|
>

|








114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
<p>A different temporary file is created each time, so that just like as
with the special ":memory:" string, two database connections to temporary
databases each have their own private database.  Temporary databases are
automatically deleted when the connection that created them closes.</p>

<p>Even though a disk file is allocated for each temporary database, in
practice the temporary database usually resides in the in-memory pager
cache and hence there is very little difference between a pure in-memory
database
created by ":memory:" and a temporary database created by an empty filename.
The only difference is that a ":memory:" database must remain in memory
at all times whereas parts of a temporary database might be flushed to
disk if database becomes large or if SQLite comes under memory pressure.</p>

<p>The previous paragraphs describe the behavior of temporary databases
under the default SQLite configuration.  An application can use the
[temp_store pragma] and the [SQLITE_TEMP_STORE] compile-time parameter to
force temporary databases to behave as pure in-memory databases, if desired.
</p>

Changes to pages/prosupport.in.

240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
a suite of test cases for SQLite that provide 100% branch test coverage
(and 100% modified condition/decision coverage) for the core SQLite in
an as-deployed configuration using only published and documented interfaces.
TH3 is designed for use with embedded devices, and is compatible with
DO-178B.  Every release of the public-domain SQLite is tested using TH3,
and so all users benefit from the TH3 tests.  But the TH3 tests are not
themselves public.  Hardware or system manufactures who want to have
TH3 test run on their systems can negotiation a service agreement to have
the SQLite Developers run those tests.</p>

<h2>About The SQLite Team</h2>

<p>Paid support options and products are provided by
Hipp, Wyrick &amp; Company, Inc., (Hwaci), a 
<a href="http://en.wikipedia.org/wiki/Georgia_(U.S._state)">Georgia</a>







|







240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
a suite of test cases for SQLite that provide 100% branch test coverage
(and 100% modified condition/decision coverage) for the core SQLite in
an as-deployed configuration using only published and documented interfaces.
TH3 is designed for use with embedded devices, and is compatible with
DO-178B.  Every release of the public-domain SQLite is tested using TH3,
and so all users benefit from the TH3 tests.  But the TH3 tests are not
themselves public.  Hardware or system manufactures who want to have
TH3 test run on their systems can negotiate a service agreement to have
the SQLite Developers run those tests.</p>

<h2>About The SQLite Team</h2>

<p>Paid support options and products are provided by
Hipp, Wyrick &amp; Company, Inc., (Hwaci), a 
<a href="http://en.wikipedia.org/wiki/Georgia_(U.S._state)">Georgia</a>