Documentation Source Text

Check-in [a17575cedc]
Login

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

Overview
Comment:Merge in fixes from the 3.8.8 branch.
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1: a17575cedc693d0d775e5b501d9bc786c6ba1648
User & Date: drh 2015-03-23 13:25:49
Context
2015-03-23
20:07
Add sqlite3_status64() to the change log. check-in: 0f26ee931b user: drh tags: trunk
13:25
Merge in fixes from the 3.8.8 branch. check-in: a17575cedc user: drh tags: trunk
13:24
Escape less-than characters in code examples. check-in: b6106e65ef user: drh tags: trunk
2015-03-16
22:22
Fix typos in the FAQ. Leaf check-in: 973dd7c44b user: drh tags: branch-3.8.8
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to pages/faq.in.

520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
  experience by billions of users.</p>

  <p>That said, there are a number of things that external programs or bugs
  in your hardware or OS can do to corrupt a database file.  See
  <a href="howtocorrupt.html">How To Corrupt An SQLite Database File</a> for
  further information.

  <p>Your can use <a href="pragma.html#pragma_integrity_check">PRAGMA integrity_check</a> 
  to do a thorough but time intensive test of the database integrity.</p>

  <p>Your can use <a href="pragma.html#pragma_quick_check">PRAGMA quick_check</a> to do a faster 
  but less thorough test of the database integrity.</p>

  <p>Depending how badly your database is corrupted, you may be able to 
  recover some of the data by using the CLI to dump the schema and contents
  to a file and then recreate.  Unfortunately, once humpty-dumpty falls off 
  the wall, it is generally not possible to put him back together again.</p>
}







|


|







520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
  experience by billions of users.</p>

  <p>That said, there are a number of things that external programs or bugs
  in your hardware or OS can do to corrupt a database file.  See
  <a href="howtocorrupt.html">How To Corrupt An SQLite Database File</a> for
  further information.

  <p>You can use <a href="pragma.html#pragma_integrity_check">PRAGMA integrity_check</a> 
  to do a thorough but time intensive test of the database integrity.</p>

  <p>You can use <a href="pragma.html#pragma_quick_check">PRAGMA quick_check</a> to do a faster 
  but less thorough test of the database integrity.</p>

  <p>Depending how badly your database is corrupted, you may be able to 
  recover some of the data by using the CLI to dump the schema and contents
  to a file and then recreate.  Unfortunately, once humpty-dumpty falls off 
  the wall, it is generally not possible to put him back together again.</p>
}

Changes to pages/isolation.in.

91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
is flushed to disk and while all changes are still held in the writer's
private memory space.  But before any changes are made to the database file
on disk, all readers must be (temporally) expelled in order to give the writer
exclusive access to the database file.  
Hence, readers are prohibited from seeing incomplete
transactions by virtue of being locked out of the database while the
transaction is being written to disk.  Only after the transaction is
complete written and synced to disk and commits are the readers allowed
back into the database.  Hence readers never get a chance to see partially
written changes.
</p>

<p>
WAL mode permits simultaneous readers and writers.  It can do this because
changes do not overwrite the original database file, but rather go







|







91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
is flushed to disk and while all changes are still held in the writer's
private memory space.  But before any changes are made to the database file
on disk, all readers must be (temporally) expelled in order to give the writer
exclusive access to the database file.  
Hence, readers are prohibited from seeing incomplete
transactions by virtue of being locked out of the database while the
transaction is being written to disk.  Only after the transaction is
completely written and synced to disk and commits are the readers allowed
back into the database.  Hence readers never get a chance to see partially
written changes.
</p>

<p>
WAL mode permits simultaneous readers and writers.  It can do this because
changes do not overwrite the original database file, but rather go

Changes to pages/queryplanner.in.

193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
</p>

<h3>1.4 Multiple Result Rows</h3>

<p>
In the previous query the fruit='Peach' constraint narrowed the result
down to a single row.  But the same technique works even if multiple
rows are obtained.  Suppose we looked up the price of Oranges instead 
Peaches:
</p>

<tcl>
code {SELECT price FROM fruitsforsale WHERE fruit='Orange'}
figure 6 #fig6 idx1lu2.gif {Indexed Lookup For The Price Of Oranges}
</tcl>







|







193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
</p>

<h3>1.4 Multiple Result Rows</h3>

<p>
In the previous query the fruit='Peach' constraint narrowed the result
down to a single row.  But the same technique works even if multiple
rows are obtained.  Suppose we looked up the price of Oranges instead of
Peaches:
</p>

<tcl>
code {SELECT price FROM fruitsforsale WHERE fruit='Orange'}
figure 6 #fig6 idx1lu2.gif {Indexed Lookup For The Price Of Oranges}
</tcl>