Documentation Source Text

Check-in [faf1f46a56]
Login

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

Overview
Comment:Fix typo in the when-to-use document.
Downloads: Tarball | ZIP archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1: faf1f46a568b3ae05ec7a02916fb1bbb5bd7b8fc
User & Date: drh 2016-07-15 02:59:49.623
Context
2016-07-22
15:23
Update docs for sqlite3_trace_v2(). (Leaf check-in: f5fc8bf5d8 user: drh tags: sqlite3_trace_v2)
2016-07-20
19:51
Fix typo in the how-to-corrupt document. (check-in: d23e6d047a user: mistachkin tags: trunk)
2016-07-15
02:59
Fix typo in the when-to-use document. (check-in: faf1f46a56 user: drh tags: trunk)
2016-07-13
14:17
Convert the RTree documentation to fancy-format. (check-in: cb9d13f931 user: drh tags: trunk)
Changes
Unified Diff Ignore Whitespace Patch
Changes to pages/whentouse.in.
︙︙
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254

<ul>
<li><p><b>Client/Server Applications</b><p>

<p>If there are many client programs sending SQL to the same 
database over a network, then use a client/server database
engine instead of SQLite.  SQLite will work over a network filesystem,
but because of the latency associated with most network filesystems,
performance will not be great.  Also, file locking logic is buggy
many network filesystem implementations (on both Unix and Windows).
If file locking does not work correctly,
two or more clients might try to modify the
same part of the same database at the same time, resulting in 
corruption.  Because this problem results from bugs in
the underlying filesystem implementation, there is nothing SQLite
can do to prevent it.</p>








|








240
241
242
243
244
245
246
247
248
249
250
251
252
253
254

<ul>
<li><p><b>Client/Server Applications</b><p>

<p>If there are many client programs sending SQL to the same 
database over a network, then use a client/server database
engine instead of SQLite.  SQLite will work over a network filesystem,
but because of the latency associated with most network filesystems,
performance will not be great.  Also, file locking logic is buggy in
many network filesystem implementations (on both Unix and Windows).
If file locking does not work correctly,
two or more clients might try to modify the
same part of the same database at the same time, resulting in 
corruption.  Because this problem results from bugs in
the underlying filesystem implementation, there is nothing SQLite
can do to prevent it.</p>
︙︙