Documentation Source Text

Check-in [ac93c65159]
Login

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

Overview
Comment:Fix documentation typos in testing.html and in fileformat2.html.
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1: ac93c6515908d1b4a4b8a19fb530be2d27bd6618
User & Date: drh 2010-09-29 04:20:00
Context
2010-09-29
11:10
Change "'CREATE TABLE AS' statements" to "'CREATE TABLE ... AS SELECT ...' statements" on lang_createtable.html. check-in: 4534ea5789 user: dan tags: trunk
04:20
Fix documentation typos in testing.html and in fileformat2.html. check-in: ac93c65159 user: drh tags: trunk
01:38
Various documentation typo fixes and updates. check-in: 161f14d929 user: drh tags: trunk
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to pages/fileformat2.in.

393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
^If L is greater than zero then integers with array indexes between 2 and
L+1 inclusive contain page numbers for freelist leaf pages.</p>

<p>Freelist leaf pages contain no information.  ^SQLite avoids reading or
writing freelist leaf pages in order to reduce disk I/O.</p>

<p>A bug in SQLite versions prior to 3.6.0 caused the database to be
reported as corrupt if any last 6 entries in the freelist trunk page 
array contained non-zero values.  Newer versions of SQLite do not have
this problem.  ^However, newer versions of SQLite still avoid using the 
last six entries in the freelist trunk page array in order that database
files created by newer versions of SQLite can be read by older versions
of SQLite.</p>

<p>^The number of freelist pages is stored as a 4-byte big-endian integer







|







393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
^If L is greater than zero then integers with array indexes between 2 and
L+1 inclusive contain page numbers for freelist leaf pages.</p>

<p>Freelist leaf pages contain no information.  ^SQLite avoids reading or
writing freelist leaf pages in order to reduce disk I/O.</p>

<p>A bug in SQLite versions prior to 3.6.0 caused the database to be
reported as corrupt if any of the last 6 entries in the freelist trunk page 
array contained non-zero values.  Newer versions of SQLite do not have
this problem.  ^However, newer versions of SQLite still avoid using the 
last six entries in the freelist trunk page array in order that database
files created by newer versions of SQLite can be read by older versions
of SQLite.</p>

<p>^The number of freelist pages is stored as a 4-byte big-endian integer

Changes to pages/testing.in.

721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
...
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751

<tcl>hd_fragment disopttest</tcl>
<h2>9.0 Disabled Optimization Tests</h2>

<p>The [sqlite3_test_control]([SQLITE_TESTCTRL_OPTIMIZATIONS], ...) interface
allows selected SQL statement optimizations to be disabled at run-time.
SQLite should always generate exactly the same answer with optimizations
enabled as with optimizations disable; the answer simply arrives quicker
with the optimizations turned on.  So in a production environment, one always
leaves the optimizations turned on (the default setting).</p>

<p>One verification technique used on SQLite is to run an entire test suite
twice, once with optimizations left on and a second time with optimizations
turned off, and verify that the same output is obtained both times.  This
verifies that the optimizations do not introduce errors.</p>
................................................................................
<p>Not all test cases can be handled this way.  Some test cases check
to verify that the optimizations really are reducing the amount of
computation by counting the number of disk accesses, sort operations, 
full-scan steps, or other processing steps that occur during queries.
Those test cases will appear to fail when optimizations are disabled.
But the majority of test cases simply look to see if the correct answer
was obtained, and all of those cases can be run successfully with and
without the optimizations, in order to show that the optimizations do
cause malfunctions.</p>

<tcl>hd_fragment staticanalysis</tcl>
<h2>10.0 Static Analysis</h2>

<p>Static analysis means analyzing code at or before compile-time to
check for correctness.  Static analysis consists mostly of making







|







 







|







721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
...
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751

<tcl>hd_fragment disopttest</tcl>
<h2>9.0 Disabled Optimization Tests</h2>

<p>The [sqlite3_test_control]([SQLITE_TESTCTRL_OPTIMIZATIONS], ...) interface
allows selected SQL statement optimizations to be disabled at run-time.
SQLite should always generate exactly the same answer with optimizations
enabled and with optimizations disabled; the answer simply arrives quicker
with the optimizations turned on.  So in a production environment, one always
leaves the optimizations turned on (the default setting).</p>

<p>One verification technique used on SQLite is to run an entire test suite
twice, once with optimizations left on and a second time with optimizations
turned off, and verify that the same output is obtained both times.  This
verifies that the optimizations do not introduce errors.</p>
................................................................................
<p>Not all test cases can be handled this way.  Some test cases check
to verify that the optimizations really are reducing the amount of
computation by counting the number of disk accesses, sort operations, 
full-scan steps, or other processing steps that occur during queries.
Those test cases will appear to fail when optimizations are disabled.
But the majority of test cases simply look to see if the correct answer
was obtained, and all of those cases can be run successfully with and
without the optimizations, in order to show that the optimizations do not
cause malfunctions.</p>

<tcl>hd_fragment staticanalysis</tcl>
<h2>10.0 Static Analysis</h2>

<p>Static analysis means analyzing code at or before compile-time to
check for correctness.  Static analysis consists mostly of making