Documentation Source Text

Check-in [f1676af6d8]
Login

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

Overview
Comment:Add the new Kreibich book. Add preliminary documentation on WAL pragmas. Refactor the pragma.html document.
Downloads: Tarball | ZIP archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1: f1676af6d8151947d54cf0ad84d1023893ec903b
User & Date: drh 2010-05-07 02:46:29.000
Context
2010-05-07
16:18
Fleshing out the WAL documentation. (check-in: a7c7d3a520 user: drh tags: trunk)
02:46
Add the new Kreibich book. Add preliminary documentation on WAL pragmas. Refactor the pragma.html document. (check-in: f1676af6d8 user: drh tags: trunk)
2010-05-06
23:48
Minor edits on the way toward 3.7.0 documentation. The wal.html document is created but is still mostly just a stub. (check-in: 019b60379f user: drh tags: trunk)
Changes
Unified Diff Ignore Whitespace Patch
Added images/books/kreibich.gif.

cannot compute difference between binary files

Changes to pages/about.in.
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
<li> <a href="features.html">Features</a> </li>
<li> <a href="faq.html">Frequently Asked Questions</a> </li>
<li> <a href="famous.html">Well-known Users</a> </li>
<li> <a href="books.html">Books About SQLite</a> </li>
<li> <a href="quickstart.html">Getting Started</a> </li>
<li> <a href="lang.html">SQL Syntax</a>
<ul>
<li> <a href="pragma.html">Pragmas</a>
<li> <a href="lang_corefunc.html">SQL functions</a>
<li> <a href="lang_datefunc.html">Date &amp; time functions</a>
<li> <a href="lang_aggfunc.html">Aggregate functions</a>
</ul>
</li>
<li> <a href="c3ref/intro.html">C/C++ Interface Spec</a>
<ul>







|







9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
<li> <a href="features.html">Features</a> </li>
<li> <a href="faq.html">Frequently Asked Questions</a> </li>
<li> <a href="famous.html">Well-known Users</a> </li>
<li> <a href="books.html">Books About SQLite</a> </li>
<li> <a href="quickstart.html">Getting Started</a> </li>
<li> <a href="lang.html">SQL Syntax</a>
<ul>
<li> <a href="pragma.html#toc">Pragmas</a>
<li> <a href="lang_corefunc.html">SQL functions</a>
<li> <a href="lang_datefunc.html">Date &amp; time functions</a>
<li> <a href="lang_aggfunc.html">Aggregate functions</a>
</ul>
</li>
<li> <a href="c3ref/intro.html">C/C++ Interface Spec</a>
<ul>
Changes to pages/books.in.
1
2
3
4
5




























6
7
8
9
10
11
12
<title>Books About SQLite</title>
<tcl>hd_keywords {books about SQLite}</tcl>

<h1 align=center>Books About SQLite</h1>





























<hr>
<table border=0>
<tr><td valign=top><img src="images/books/symbiansql.jpg"><td valign=top>
<h2>Inside Symbian SQL (2010)</h2>

<p>Authors: Ivan Litovski &amp; Richard Maynard<br>
Publisher: Wiley<br>





>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>







1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
<title>Books About SQLite</title>
<tcl>hd_keywords {books about SQLite}</tcl>

<h1 align=center>Books About SQLite</h1>

<hr>
<table border=0><tr><td valign=top><p><img src="images/books/kreibich.gif">
<td valign=top>
<h2>Using SQLite (2010)</h2>

<p>
Author: Jay A. Kreibich<br>
Publisher: O'Reilly Media<br>
<a href="http://oreilly.com/catalog/9780596521196/">O'Reilly</a></p>

<p>Developers, take note: databases aren't just for the IS group any more.
You can build database-backed applications for the desktop, Web,
embedded systems, or operating systems without linking to heavy-duty
client-server databases such as Oracle and MySQL. 
This book shows how you to use SQLite, a small and lightweight 
database that you can build right into your application during development.
Applications that handle data have an enormous advantage today, and
with SQLite, you'll discover how to develop a database-backed application
that remains manageable in size and complexity. This book guides
you every step of the way. You'll get a crash course in data modeling, 
become familiar with SQLite's dialect of the SQL database language, 
and learn how you to work with SQLite using either a scripting 
language or a C-based language, such as C# or Objective C.Now, 
even relatively small and nimble applications can be a part of 
the data revolution. Using SQLite shows you how.
</p>
</table>

<hr>
<table border=0>
<tr><td valign=top><img src="images/books/symbiansql.jpg"><td valign=top>
<h2>Inside Symbian SQL (2010)</h2>

<p>Authors: Ivan Litovski &amp; Richard Maynard<br>
Publisher: Wiley<br>
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
<p>This text is written in fluent Japanese specifically for a Japanese
audience.  This is the second edition of the book - the first edition
was published in 2005.  
</p>
</table>

<hr>
<table border=0><tr><td valign=top><img src="images/books/haldar.gif">
<td valign=top>
<h2>Inside SQLite (2007)</h2>

<p>
Author: Sibsankar Haldar<br>
Publisher: O'Reilly Media<br>
<a href="http://oreilly.com/catalog/9780596550066">O'Reilly</a></p>







|







88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
<p>This text is written in fluent Japanese specifically for a Japanese
audience.  This is the second edition of the book - the first edition
was published in 2005.  
</p>
</table>

<hr>
<table border=0><tr><td valign=top><p><img src="images/books/haldar.gif">
<td valign=top>
<h2>Inside SQLite (2007)</h2>

<p>
Author: Sibsankar Haldar<br>
Publisher: O'Reilly Media<br>
<a href="http://oreilly.com/catalog/9780596550066">O'Reilly</a></p>
Changes to pages/index.in.
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
<p><ul>
<li> <a href="features.html">Features</a> </li>
<li> <a href="faq.html">Frequently Asked Questions</a> </li>
<li> <a href="famous.html">Well-known Users</a> </li>
<li> <a href="quickstart.html">Getting Started</a> </li>
<li> <a href="lang.html">SQL Syntax</a>
<ul>
<li> <a href="pragma.html">Pragmas</a>
<li> <a href="lang_corefunc.html">SQL functions</a>
<li> <a href="lang_datefunc.html">Date &amp; time functions</a>
<li> <a href="lang_aggfunc.html">Aggregate functions</a>
</ul>
</li>
<li> <a href="c3ref/intro.html">C/C++ Interface Spec</a>
<ul>







|







91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
<p><ul>
<li> <a href="features.html">Features</a> </li>
<li> <a href="faq.html">Frequently Asked Questions</a> </li>
<li> <a href="famous.html">Well-known Users</a> </li>
<li> <a href="quickstart.html">Getting Started</a> </li>
<li> <a href="lang.html">SQL Syntax</a>
<ul>
<li> <a href="pragma.html#toc">Pragmas</a>
<li> <a href="lang_corefunc.html">SQL functions</a>
<li> <a href="lang_datefunc.html">Date &amp; time functions</a>
<li> <a href="lang_aggfunc.html">Aggregate functions</a>
</ul>
</li>
<li> <a href="c3ref/intro.html">C/C++ Interface Spec</a>
<ul>
Changes to pages/pragma.in.
1

2
3
4
5
6
7
8
9
10
11
12
13

14



15
16

17
18
19
20





21
22
23
24
25
26
27
28
<title>Pragma statements supported by SQLite</title>


<tcl>
proc Section {name {label {}} {keywords {}}} {
  hd_puts "\n<hr />"
  if {$label!=""} {
    hd_fragment $label
    if {$keywords!=""} {
      eval hd_keywords $keywords
    }
  }
  hd_puts "<h1>$name</h1>\n"
}

proc Subsection {args} {



  set f [lindex $args 0]
  hd_fragment pragma_$f

  foreach x $args {
    hd_keywords *$x "PRAGMA $x" "$x pragma"
  }
}






</tcl>

<p>The PRAGMA statement is a SQL extension specific to SQLite and used to 
modify the operation of the SQLite library or to query the SQLite library for 
internal (non-table) data. The PRAGMA statement is issued using the same
interface as other SQLite commands (e.g. [SELECT], [INSERT]) but is
different in the following important respects:

>










|

>
|
>
>
>
|
|
>
|
|


>
>
>
>
>
|







1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
<title>Pragma statements supported by SQLite</title>
<h1 align="center">PRAGMA Statements</h1>

<tcl>
proc Section {name {label {}} {keywords {}}} {
  hd_puts "\n<hr />"
  if {$label!=""} {
    hd_fragment $label
    if {$keywords!=""} {
      eval hd_keywords $keywords
    }
  }
  hd_puts "<h2>$name</h2>\n"
}
unset -nocomplain PragmaBody PragmaRef PragmaDud PragmaKeys

# Each pragma is recorded by invoking this procedure.
proc Pragma {namelist content} {
  global PragmaBody PragmaRef PragmaKeys
  set main_name [lindex $namelist 0]
  set PragmaBody($main_name) $content
  set PragmaKeys($main_name) $namelist
  foreach x $namelist {
    set PragmaRef($x) $main_name
  }
}
# Legacy pragma
proc LegacyPragma {namelist content} {
  Pragma $namelist $content
  global PragmaLegacy
  foreach x $namelist {set PragmaLegacy($x) 1}
}
</tcl>

<p>The PRAGMA statement is a SQL extension specific to SQLite and used to 
modify the operation of the SQLite library or to query the SQLite library for 
internal (non-table) data. The PRAGMA statement is issued using the same
interface as other SQLite commands (e.g. [SELECT], [INSERT]) but is
different in the following important respects:
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
    SQL statements.  Whether or not the pragma runs during sqlite3_prepare()
    or sqlite3_step() depends on the pragma and on the specific release
    of SQLite.
<li>The pragma command is specific to SQLite and is very unlikely 
    to be compatible with any other SQL database engine.
</ul>

<p>The available pragmas fall into four basic categories:</p>
<ul>
<li>Pragmas used to <a href="#modify">modify the operation</a> of the 
    SQLite library in some manner, or to query for the current mode of 
    operation.
<li>Pragmas used to <a href="#schema">query the schema</a> of the current 
    database.
<li>Pragmas used to <a href="#version">query or modify the two 
    version counters stored in the database:</a>
    the schema-version and the user-version.
<li>Pragmas used to <a href="#debug">debug the library</a> and verify that
    database files are not corrupted.
</ul>

<tcl>
Section {PRAGMA command syntax} syntax {PRAGMA}

BubbleDiagram pragma-stmt
BubbleDiagram pragma-value
</tcl>








<
<
<
<
<
<
<
<
<
<
<
<
<
<







53
54
55
56
57
58
59














60
61
62
63
64
65
66
    SQL statements.  Whether or not the pragma runs during sqlite3_prepare()
    or sqlite3_step() depends on the pragma and on the specific release
    of SQLite.
<li>The pragma command is specific to SQLite and is very unlikely 
    to be compatible with any other SQL database engine.
</ul>















<tcl>
Section {PRAGMA command syntax} syntax {PRAGMA}

BubbleDiagram pragma-stmt
BubbleDiagram pragma-value
</tcl>

88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103

104
105
106
107
108
109
110

111
112
113
114
115
116
117
118
119

<p>^A pragma may have an optional database name before the pragma name.
^The database name is the name of an [ATTACH]-ed database or it can be
"main" or "temp" for the main and the TEMP databases.  ^If the optional
database name is omitted, "main" is assumed.  ^In some pragmas, the database
name is meaningless and is simply ignored.</p>

<tcl>Section {Pragmas to modify library operation} modify</tcl>
</tcl>

<ul>
<tcl>Subsection automatic_index</tcl>
<li><p>^(<b>PRAGMA automatic_index;
       <br>PRAGMA automatic_index = </b><i>boolean</i><b>;</b></p>
    <p>Query, set, or clear the [automatic indexing] capability.)^


    <p>^[Automatic indexing] is enabled by default.
     ^This pragma only influences the query plan as statements are
     prepared or reprepared.  Existing prepared statements must be
     reprepared for a change in the automatic_index setting to affect
     their operation.
</li>


<tcl>Subsection auto_vacuum</tcl>
<li><p><b>PRAGMA auto_vacuum;<br>
          PRAGMA auto_vacuum = </b>
           <i>0 | NONE | 1 | FULL | 2 | INCREMENTAL</i><b>;</b></p>

    <p>Query or set the auto-vacuum status in the database.</p>

    <p>^The default setting for auto-vacuum is 0 or "none",
    unless the [SQLITE_DEFAULT_AUTOVACUUM] compile-time option is used.







<
<

<
|
|
|
<

>





<
|
>
|
|







85
86
87
88
89
90
91


92

93
94
95

96
97
98
99
100
101
102

103
104
105
106
107
108
109
110
111
112
113

<p>^A pragma may have an optional database name before the pragma name.
^The database name is the name of an [ATTACH]-ed database or it can be
"main" or "temp" for the main and the TEMP databases.  ^If the optional
database name is omitted, "main" is assumed.  ^In some pragmas, the database
name is meaningless and is simply ignored.</p>





<tcl>Pragma {automatic_index} {
    <p>^(<b>PRAGMA automatic_index;
     <br>PRAGMA automatic_index = </b><i>boolean</i><b>;</b></p>


    <p>Query, set, or clear the [automatic indexing] capability.)^
    <p>^[Automatic indexing] is enabled by default.
     ^This pragma only influences the query plan as statements are
     prepared or reprepared.  Existing prepared statements must be
     reprepared for a change in the automatic_index setting to affect
     their operation.

}

Pragma {auto_vacuum} {
    <p><b>PRAGMA auto_vacuum;<br>
          PRAGMA auto_vacuum = </b>
           <i>0 | NONE | 1 | FULL | 2 | INCREMENTAL</i><b>;</b></p>

    <p>Query or set the auto-vacuum status in the database.</p>

    <p>^The default setting for auto-vacuum is 0 or "none",
    unless the [SQLITE_DEFAULT_AUTOVACUUM] compile-time option is used.
158
159
160
161
162
163
164
165
166

167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187

188
189
190
191
192
193
194
195
196
197
198
199
200

201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220

221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
    reorganize the entire database file.  ^To change from "full" or
    "incremental" back to "none" always requires running [VACUUM] even
    on an empty database.
    </p>

    <p>^When the auto_vacuum pragma is invoked with no arguments, it
    returns the current auto_vacuum mode.</p>
    </li>


<tcl>Subsection cache_size</tcl>
<li><p>^(<b>PRAGMA cache_size;
       <br>PRAGMA cache_size = </b><i>Number-of-pages</i><b>;</b></p>
    <p>Query or change the suggested maximum number of database disk pages
    that SQLite will hold in memory at once per open database file.)^  ^Whether
    or not this suggestion is honored is at the discretion of the
    [sqlite3_pcache_methods | Application Defined Page Cache].   ^In the
    default page cache implemention, the suggested cache size is honored
    as long as it is 10 or greater.  ^A suggested cache size of less
    than 10 are treated as if it were 10.
    ^Alternative application-defined page cache implementations
    may choose to interpret the suggested cache size in different ways
    or to ignore it all together.
    ^The default suggested cache size is 2000.</p>

    <p>^When you change the cache size using the cache_size pragma, the
    change only endures for the current session.  ^The cache size reverts
    to the default value when the database is closed and reopened.  Use
    the [default_cache_size]
    pragma to check the cache size permanently.</p></li>


<tcl>Subsection case_sensitive_like</tcl>
<li><p>^(<b>PRAGMA case_sensitive_like = </b><i>boolean</i><b>;</b>)^</p>
    <p>^The default behavior of the [LIKE] operator is to ignore case
    for ASCII characters. ^Hence, by default <b>'a' LIKE 'A'</b> is
    true.  ^The case_sensitive_like pragma installs a new application-defined
    LIKE function that can change
    this behavior.  ^When case_sensitive_like is enabled,
    <b>'a' LIKE 'A'</b> is false but <b>'a' LIKE 'a'</b> is still true.</p>

    <p>^This pragma only works if the [like | built-in like() SQL function]
    has not been overloaded using [sqlite3_create_function()].</p>
    </li>


<tcl>Subsection count_changes</tcl>
<li><p>^(<b>PRAGMA count_changes;
       <br>PRAGMA count_changes = </b>boolean</i><b>;</b></p>
    <p>Query or change the count-changes flag.)^ ^Normally, when the
    count-changes flag is not set, [INSERT], [UPDATE] and [DELETE] statements
    return no data. ^When count-changes is set, each of these commands 
    returns a single row of data consisting of one integer value - the
    number of rows inserted, modified or deleted by the command. ^The 
    returned change count does not include any insertions, modifications
    or deletions performed by triggers, or any changes made automatically
    by [foreign key actions].</p>

    <p>Another way to get the row change counts is to use the
    [sqlite3_changes()] or [sqlite3_total_changes()] interfaces.
    There is a subtle different, though.  ^When an INSERT, UPDATE, or
    DELETE is run against a view using an [INSTEAD OF trigger],
    the count_changes pragma reports the number of rows in the view
    that fired the trigger, whereas [sqlite3_changes()] and
    [sqlite3_total_changes()] do not.</p>


<tcl>Subsection default_cache_size</tcl>
<li><p>^(<b>PRAGMA default_cache_size;
       <br>PRAGMA default_cache_size = </b><i>Number-of-pages</i><b>;</b></p>
    <p>This pragma queries or sets the suggested maximum number of pages
    of disk cache that will be allocated per open database file.)^
    ^The difference between this pragma and [cache_size] is that the
    value set here persists across database connections.
    </p></li>


<tcl>Subsection empty_result_callbacks</tcl>
<li><p><b>PRAGMA empty_result_callbacks;
       <br>PRAGMA empty_result_callbacks = </b><i>boolean</i><b>;</b></p>

    <p>Query or change the empty-result-callbacks flag.</p>

    <p>The empty-result-callbacks flag affects the [sqlite3_exec()] API only.
    Normally, when the empty-result-callbacks flag is cleared, the
    callback function supplied to the [sqlite3_exec()] is not invoked
    for commands that return zero rows of data.  When empty-result-callbacks
    is set in this situation, the callback function is invoked exactly once,
    with the third parameter set to 0 (NULL). This is to enable programs  
    that use the [sqlite3_exec()] API to retrieve column-names even when
    a query returns no data.</p>

    <p>This pragma is legacy.  It was created long ago in the early
    days of SQLite before the prepared statement interface was available.
    Do not use this pragma.  It is likely to go away in a future release</p>
   
    

<tcl>Subsection encoding</tcl>
<li><p>^(<b>PRAGMA encoding;
       <br>PRAGMA encoding = "UTF-8";
       <br>PRAGMA encoding = "UTF-16";
       <br>PRAGMA encoding = "UTF-16le";
       <br>PRAGMA encoding = "UTF-16be";</b>)^</p>
    <p>^In first form, if the main database has already been
    created, then this pragma returns the text encoding used by the
    main database, one of "UTF-8", "UTF-16le" (little-endian UTF-16







<
|
>
|
|

















|
|
>
|
|









<
|
>
|
|
















|
|
>
|
|





|
|

|
|
















|


|
|







152
153
154
155
156
157
158

159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193

194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
    reorganize the entire database file.  ^To change from "full" or
    "incremental" back to "none" always requires running [VACUUM] even
    on an empty database.
    </p>

    <p>^When the auto_vacuum pragma is invoked with no arguments, it
    returns the current auto_vacuum mode.</p>

}

Pragma cache_size {
    <p>^(<b>PRAGMA cache_size;
       <br>PRAGMA cache_size = </b><i>Number-of-pages</i><b>;</b></p>
    <p>Query or change the suggested maximum number of database disk pages
    that SQLite will hold in memory at once per open database file.)^  ^Whether
    or not this suggestion is honored is at the discretion of the
    [sqlite3_pcache_methods | Application Defined Page Cache].   ^In the
    default page cache implemention, the suggested cache size is honored
    as long as it is 10 or greater.  ^A suggested cache size of less
    than 10 are treated as if it were 10.
    ^Alternative application-defined page cache implementations
    may choose to interpret the suggested cache size in different ways
    or to ignore it all together.
    ^The default suggested cache size is 2000.</p>

    <p>^When you change the cache size using the cache_size pragma, the
    change only endures for the current session.  ^The cache size reverts
    to the default value when the database is closed and reopened.  Use
    the [default_cache_size]
    pragma to check the cache size permanently.</p>
}

Pragma case_sensitive_like {
    <p>^(<b>PRAGMA case_sensitive_like = </b><i>boolean</i><b>;</b>)^</p>
    <p>^The default behavior of the [LIKE] operator is to ignore case
    for ASCII characters. ^Hence, by default <b>'a' LIKE 'A'</b> is
    true.  ^The case_sensitive_like pragma installs a new application-defined
    LIKE function that can change
    this behavior.  ^When case_sensitive_like is enabled,
    <b>'a' LIKE 'A'</b> is false but <b>'a' LIKE 'a'</b> is still true.</p>

    <p>^This pragma only works if the [like | built-in like() SQL function]
    has not been overloaded using [sqlite3_create_function()].</p>

}

Pragma count_changes {
    <p>^(<b>PRAGMA count_changes;
       <br>PRAGMA count_changes = </b>boolean</i><b>;</b></p>
    <p>Query or change the count-changes flag.)^ ^Normally, when the
    count-changes flag is not set, [INSERT], [UPDATE] and [DELETE] statements
    return no data. ^When count-changes is set, each of these commands 
    returns a single row of data consisting of one integer value - the
    number of rows inserted, modified or deleted by the command. ^The 
    returned change count does not include any insertions, modifications
    or deletions performed by triggers, or any changes made automatically
    by [foreign key actions].</p>

    <p>Another way to get the row change counts is to use the
    [sqlite3_changes()] or [sqlite3_total_changes()] interfaces.
    There is a subtle different, though.  ^When an INSERT, UPDATE, or
    DELETE is run against a view using an [INSTEAD OF trigger],
    the count_changes pragma reports the number of rows in the view
    that fired the trigger, whereas [sqlite3_changes()] and
    [sqlite3_total_changes()] do not.
}

LegacyPragma default_cache_size {
    ^(<b>PRAGMA default_cache_size;
       <br>PRAGMA default_cache_size = </b><i>Number-of-pages</i><b>;</b></p>
    <p>This pragma queries or sets the suggested maximum number of pages
    of disk cache that will be allocated per open database file.)^
    ^The difference between this pragma and [cache_size] is that the
    value set here persists across database connections.
    </p>
}

LegacyPragma empty_result_callbacks {
    <p><b>PRAGMA empty_result_callbacks;
       <br>PRAGMA empty_result_callbacks = </b><i>boolean</i><b>;</b></p>

    <p>Query or change the empty-result-callbacks flag.</p>

    <p>The empty-result-callbacks flag affects the [sqlite3_exec()] API only.
    Normally, when the empty-result-callbacks flag is cleared, the
    callback function supplied to the [sqlite3_exec()] is not invoked
    for commands that return zero rows of data.  When empty-result-callbacks
    is set in this situation, the callback function is invoked exactly once,
    with the third parameter set to 0 (NULL). This is to enable programs  
    that use the [sqlite3_exec()] API to retrieve column-names even when
    a query returns no data.</p>

    <p>This pragma is legacy.  It was created long ago in the early
    days of SQLite before the prepared statement interface was available.
    Do not use this pragma.  It is likely to go away in a future release</p>
}   
    

Pragma encoding {
   <p>^(<b>PRAGMA encoding;
       <br>PRAGMA encoding = "UTF-8";
       <br>PRAGMA encoding = "UTF-16";
       <br>PRAGMA encoding = "UTF-16le";
       <br>PRAGMA encoding = "UTF-16be";</b>)^</p>
    <p>^In first form, if the main database has already been
    created, then this pragma returns the text encoding used by the
    main database, one of "UTF-8", "UTF-16le" (little-endian UTF-16
270
271
272
273
274
275
276
277
278

279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302

303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326

327
328
329
330
331
332
333
334
335
336

337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358

359
360
361
362
363
364
365
366
367
    and subsequent forms are used after the database file has already
    been created, they have no effect and are silently ignored.</p>

    <p>^Once an encoding has been set for a database, it cannot be changed.</p>

    <p>^Databases created by the [ATTACH] command always use the same encoding
    as the main database.</p>
</li>


<tcl>Subsection foreign_keys</tcl>
<li><p>^(<b>PRAGMA foreign_keys;
       <br>PRAGMA foreign_keys = </b><i>boolean</i><b>;</b></p>
    <p>Query, set, or clear the enforcement of [foreign key constraints].)^

    <p>^This pragma is a no-op within a transaction; foreign key constraint
       enforcement may only be enabled or disabled when there is no pending
       [BEGIN] or [SAVEPOINT].

    <p>^Changing the foreign_keys setting affects the execution of
       all statements prepared
       using the database connection, including those prepared before the
       setting was changed. ^Any existing statements prepared using the legacy 
       [sqlite3_prepare()] interface may fail with an [SQLITE_SCHEMA] error
       after the foreign_keys setting is changed.

    <p>^(As of SQLite [version 3.6.19], the default setting for foreign
       key enforcement is OFF.)^  However, that might change in a future
       release of SQLite.  To minimize future problems, applications should
       set the foreign key enforcement flag as required by the application
       and not depend on the default setting.
</li>



<tcl>Subsection full_column_names</tcl>
<li><p>^(<b>PRAGMA full_column_names;
       <br>PRAGMA full_column_names = </b><i>boolean</i><b>;</b></p>
    <p>Query or change the full_column_names flag.)^ ^This flag together 
    with the [short_column_names] flag determine
    the way SQLite assigns names to result columns of [SELECT] statements.
    ^(Result columns are named by applying the following rules in order:
    <ol>
    <li><p>If there is an AS clause on the result, then the name of
        the column is the right-hand side of the AS clause.</p></li>
    <li><p>If the result is a general expression, not a just the name of
        a source table column,
        then the name of the result is a copy of the expression text.</p></li>
    <li><p>If the [short_column_names] pragma is ON, then the name of the
        result is the name of the source table column without the 
        source table name prefix:  COLUMN.</p></li>
    <li><p>If both pragmas [short_column_names] and [full_column_names]
        are OFF then case (2) applies.
        </p></li>
    <li><p>The name of the result column is a combination of the source table
        and source column name:  TABLE.COLUMN</p></li>
    </ol>)^
</li>


<tcl>Subsection fullfsync</tcl>
<li><p>^(<b>PRAGMA fullfsync
       <br>PRAGMA fullfsync = </b><i>boolean</i><b>;</b></p>
    <p>Query or change the fullfsync flag.)^ ^This flag affects
    determines whether or not the F_FULLFSYNC syncing method is used
    on systems that support it.  ^The default value of the fullfsync flag
    is off.  Only Mac OS X supports F_FULLFSYNC.
    </p>
</li>


<tcl>Subsection incremental_vacuum</tcl>
<li><p><b>PRAGMA incremental_vacuum</b><i>(N)</i><b>;</b></p>
    <p>^The incremental_vacuum pragma causes up to <i>N</i> pages to
    be removed from the freelist.  ^The database file is truncated by
    the same amount.  ^The incremental_vacuum pragma has no effect if
    the database is not in
    <a href="#pragma_auto_vacuum">auto_vacuum==incremental</a> mode
    or if there are no pages on the freelist.  ^If there are fewer than
    <i>N</i> pages on the freelist, or if <i>N</i> is less than 1, or
    if <i>N</i> is omitted entirely, then the entire freelist is cleared.</p>

    <p>As of [version 3.4.0] (the first version that supports
    incremental_vacuum) this feature is still experimental.  Possible
    future changes include enhancing incremental vacuum to do
    defragmentation and node repacking just as the full-blown
    [VACUUM] command does.  And
    incremental vacuum may be promoted from a pragma to a separate
    SQL command, or perhaps some variation on the [VACUUM] command.
    Programmers are cautioned to not become enamored with the
    current syntax or functionality as it is likely to change.</p>
</li>


<tcl>Subsection journal_mode</tcl>
<li><p>^(<b>PRAGMA journal_mode;
       <br>PRAGMA </b><i>database</i><b>.journal_mode;
       <br>PRAGMA journal_mode
              = <i>DELETE | TRUNCATE | PERSIST | MEMORY | WAL | OFF</i>
       <br>PRAGMA </b><i>database</i><b>.journal_mode
              = <i>DELETE | TRUNCATE | PERSIST | MEMORY | WAL | OFF</i></b></p>

    <p>This pragma queries or sets the journal mode for databases







<
|
>
|
|



















<
|

>
|
|




















<
|
>
|
|






<
|
>
|
|


















<
|
>
|
|







266
267
268
269
270
271
272

273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295

296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320

321
322
323
324
325
326
327
328
329
330

331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352

353
354
355
356
357
358
359
360
361
362
363
    and subsequent forms are used after the database file has already
    been created, they have no effect and are silently ignored.</p>

    <p>^Once an encoding has been set for a database, it cannot be changed.</p>

    <p>^Databases created by the [ATTACH] command always use the same encoding
    as the main database.</p>

}

Pragma foreign_keys {
     <p>^(<b>PRAGMA foreign_keys;
       <br>PRAGMA foreign_keys = </b><i>boolean</i><b>;</b></p>
    <p>Query, set, or clear the enforcement of [foreign key constraints].)^

    <p>^This pragma is a no-op within a transaction; foreign key constraint
       enforcement may only be enabled or disabled when there is no pending
       [BEGIN] or [SAVEPOINT].

    <p>^Changing the foreign_keys setting affects the execution of
       all statements prepared
       using the database connection, including those prepared before the
       setting was changed. ^Any existing statements prepared using the legacy 
       [sqlite3_prepare()] interface may fail with an [SQLITE_SCHEMA] error
       after the foreign_keys setting is changed.

    <p>^(As of SQLite [version 3.6.19], the default setting for foreign
       key enforcement is OFF.)^  However, that might change in a future
       release of SQLite.  To minimize future problems, applications should
       set the foreign key enforcement flag as required by the application
       and not depend on the default setting.

}


LegacyPragma full_column_names {
    <p>^(<b>PRAGMA full_column_names;
       <br>PRAGMA full_column_names = </b><i>boolean</i><b>;</b></p>
    <p>Query or change the full_column_names flag.)^ ^This flag together 
    with the [short_column_names] flag determine
    the way SQLite assigns names to result columns of [SELECT] statements.
    ^(Result columns are named by applying the following rules in order:
    <ol>
    <li><p>If there is an AS clause on the result, then the name of
        the column is the right-hand side of the AS clause.</p></li>
    <li><p>If the result is a general expression, not a just the name of
        a source table column,
        then the name of the result is a copy of the expression text.</p></li>
    <li><p>If the [short_column_names] pragma is ON, then the name of the
        result is the name of the source table column without the 
        source table name prefix:  COLUMN.</p></li>
    <li><p>If both pragmas [short_column_names] and [full_column_names]
        are OFF then case (2) applies.
        </p></li>
    <li><p>The name of the result column is a combination of the source table
        and source column name:  TABLE.COLUMN</p></li>
    </ol>)^

}

Pragma fullfsync {
    <p>^(<b>PRAGMA fullfsync
       <br>PRAGMA fullfsync = </b><i>boolean</i><b>;</b></p>
    <p>Query or change the fullfsync flag.)^ ^This flag affects
    determines whether or not the F_FULLFSYNC syncing method is used
    on systems that support it.  ^The default value of the fullfsync flag
    is off.  Only Mac OS X supports F_FULLFSYNC.
    </p>

}

Pragma incremental_vacuum {
    <p><b>PRAGMA incremental_vacuum</b><i>(N)</i><b>;</b></p>
    <p>^The incremental_vacuum pragma causes up to <i>N</i> pages to
    be removed from the freelist.  ^The database file is truncated by
    the same amount.  ^The incremental_vacuum pragma has no effect if
    the database is not in
    <a href="#pragma_auto_vacuum">auto_vacuum==incremental</a> mode
    or if there are no pages on the freelist.  ^If there are fewer than
    <i>N</i> pages on the freelist, or if <i>N</i> is less than 1, or
    if <i>N</i> is omitted entirely, then the entire freelist is cleared.</p>

    <p>As of [version 3.4.0] (the first version that supports
    incremental_vacuum) this feature is still experimental.  Possible
    future changes include enhancing incremental vacuum to do
    defragmentation and node repacking just as the full-blown
    [VACUUM] command does.  And
    incremental vacuum may be promoted from a pragma to a separate
    SQL command, or perhaps some variation on the [VACUUM] command.
    Programmers are cautioned to not become enamored with the
    current syntax or functionality as it is likely to change.</p>

}

Pragma journal_mode {
    <p>^(<b>PRAGMA journal_mode;
       <br>PRAGMA </b><i>database</i><b>.journal_mode;
       <br>PRAGMA journal_mode
              = <i>DELETE | TRUNCATE | PERSIST | MEMORY | WAL | OFF</i>
       <br>PRAGMA </b><i>database</i><b>.journal_mode
              = <i>DELETE | TRUNCATE | PERSIST | MEMORY | WAL | OFF</i></b></p>

    <p>This pragma queries or sets the journal mode for databases
426
427
428
429
430
431
432
433
434

435
436
437
438
439
440
441
442
443
    set, then the database file will very likely go corrupt.</p>

    <p>^Note that the journal_mode for an [in-memory database]
    is either MEMORY or OFF and can not be changed to a different value.
    ^An attempt to change the journal_mode of an [in-memory database] to
    any setting other than MEMORY or OFF is ignored.  ^Note also that
    the journal_mode cannot be changed while a transaction is active.</p>
</li>


<tcl>Subsection journal_size_limit</tcl>
<li><p><b>
    PRAGMA journal_size_limit<br>
    PRAGMA journal_size_limit = </b><i>N</i> <b>;</b>

  <p>^If a database connection is operating in either "exclusive mode"
  (PRAGMA locking_mode=exclusive) or "persistent journal mode"
  (PRAGMA journal_mode=persist) then under certain circumstances
  after committing a transaction the journal file may remain in







<
|
>
|
|







422
423
424
425
426
427
428

429
430
431
432
433
434
435
436
437
438
439
    set, then the database file will very likely go corrupt.</p>

    <p>^Note that the journal_mode for an [in-memory database]
    is either MEMORY or OFF and can not be changed to a different value.
    ^An attempt to change the journal_mode of an [in-memory database] to
    any setting other than MEMORY or OFF is ignored.  ^Note also that
    the journal_mode cannot be changed while a transaction is active.</p>

}

Pragma journal_size_limit {
    <p><b>
    PRAGMA journal_size_limit<br>
    PRAGMA journal_size_limit = </b><i>N</i> <b>;</b>

  <p>^If a database connection is operating in either "exclusive mode"
  (PRAGMA locking_mode=exclusive) or "persistent journal mode"
  (PRAGMA journal_mode=persist) then under certain circumstances
  after committing a transaction the journal file may remain in
461
462
463
464
465
466
467
468
469
470

471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492

493
494
495
496
497
498
499
500
501
  [SQLITE_DEFAULT_JOURNAL_SIZE_LIMIT] at compile time.</p>

  <p>^This pragma only operates on the single database specified prior
  to the pragma name (or on the "main" database if no database is specified.)
  There is no way to operate on all attached databases using a single
  PRAGMA statement, nor is there a way to set the limit to use for databases
  that will be attached in the future.
</li>



<tcl>Subsection legacy_file_format</tcl>
<li><p>^(<b>PRAGMA legacy_file_format;
       <br>PRAGMA legacy_file_format = <i>boolean</i></b></p>
    <p>This pragma sets or queries the value of the legacy_file_format
    flag.)^  ^When this flag is on, new SQLite databases are created in
    a file format that is readable and writable by all versions of
    SQLite going back to 3.0.0.  ^When the flag is off, new databases
    are created using the latest file format which might not be
    readable or writable by versions of SQLite prior to 3.3.0.</p>

    <p>^When the legacy_file_format pragma is issued with no argument,
    it returns the setting of the flag.  ^This pragma does <u>not</u> tell
    which file format the current database is using; it tells what format
    will be used by any newly created databases.</p>

    <p>^(This flag only affects newly created databases.  It has no
    effect on databases that already exist.)^</p>

    <p>^The default file format is set by the
    [SQLITE_DEFAULT_FILE_FORMAT] compile-time option.</p>
</li>


<tcl>Subsection locking_mode</tcl>
<li><p>^(<b>PRAGMA locking_mode;
       <br>PRAGMA locking_mode = <i>NORMAL | EXCLUSIVE</i></b>)^</p>
    <p>^This pragma sets or queries the database connection locking-mode. 
    ^The locking-mode is either NORMAL or EXCLUSIVE.

    <p>^In NORMAL locking-mode (the default), a database connection
    unlocks the database file at the conclusion of each read or
    write transaction. ^When the locking-mode is set to EXCLUSIVE, the







<
|

>
|
|


















<
|
>
|
|







457
458
459
460
461
462
463

464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486

487
488
489
490
491
492
493
494
495
496
497
  [SQLITE_DEFAULT_JOURNAL_SIZE_LIMIT] at compile time.</p>

  <p>^This pragma only operates on the single database specified prior
  to the pragma name (or on the "main" database if no database is specified.)
  There is no way to operate on all attached databases using a single
  PRAGMA statement, nor is there a way to set the limit to use for databases
  that will be attached in the future.

}


Pragma legacy_file_format {
   <p>^(<b>PRAGMA legacy_file_format;
       <br>PRAGMA legacy_file_format = <i>boolean</i></b></p>
    <p>This pragma sets or queries the value of the legacy_file_format
    flag.)^  ^When this flag is on, new SQLite databases are created in
    a file format that is readable and writable by all versions of
    SQLite going back to 3.0.0.  ^When the flag is off, new databases
    are created using the latest file format which might not be
    readable or writable by versions of SQLite prior to 3.3.0.</p>

    <p>^When the legacy_file_format pragma is issued with no argument,
    it returns the setting of the flag.  ^This pragma does <u>not</u> tell
    which file format the current database is using; it tells what format
    will be used by any newly created databases.</p>

    <p>^(This flag only affects newly created databases.  It has no
    effect on databases that already exist.)^</p>

    <p>^The default file format is set by the
    [SQLITE_DEFAULT_FILE_FORMAT] compile-time option.</p>

}

Pragma locking_mode {
    <p>^(<b>PRAGMA locking_mode;
       <br>PRAGMA locking_mode = <i>NORMAL | EXCLUSIVE</i></b>)^</p>
    <p>^This pragma sets or queries the database connection locking-mode. 
    ^The locking-mode is either NORMAL or EXCLUSIVE.

    <p>^In NORMAL locking-mode (the default), a database connection
    unlocks the database file at the conclusion of each read or
    write transaction. ^When the locking-mode is set to EXCLUSIVE, the
531
532
533
534
535
536
537
538
539

540
541
542
543
544
545
546
547
548

   <p>^The "temp" database (in which TEMP tables and indices are stored)
   and [in-memory databases]
   always uses exclusive locking mode.  ^The locking mode of temp and
   [in-memory databases] cannot
   be changed.  ^All other databases use the normal locking mode by default
   and are affected by this pragma.</p>
</li>


<tcl>Subsection page_size</tcl>
<li><p>^(<b>PRAGMA page_size;
       <br>PRAGMA page_size = </b><i>bytes</i><b>;</b></p>
    <p>Query or set the page size of the database.)^ ^The page size
    may only be set if the database has not yet been created. ^The page
    size must be a power of two greater than or equal to 512 and less
    than or equal to [SQLITE_MAX_PAGE_SIZE].
    The maximum value for [SQLITE_MAX_PAGE_SIZE] is 32768.
    </p>







<
|
>
|
|







527
528
529
530
531
532
533

534
535
536
537
538
539
540
541
542
543
544

   <p>^The "temp" database (in which TEMP tables and indices are stored)
   and [in-memory databases]
   always uses exclusive locking mode.  ^The locking mode of temp and
   [in-memory databases] cannot
   be changed.  ^All other databases use the normal locking mode by default
   and are affected by this pragma.</p>

}

Pragma page_size {
   <p>^(<b>PRAGMA page_size;
       <br>PRAGMA page_size = </b><i>bytes</i><b>;</b></p>
    <p>Query or set the page size of the database.)^ ^The page size
    may only be set if the database has not yet been created. ^The page
    size must be a power of two greater than or equal to 512 and less
    than or equal to [SQLITE_MAX_PAGE_SIZE].
    The maximum value for [SQLITE_MAX_PAGE_SIZE] is 32768.
    </p>
573
574
575
576
577
578
579
580
581

582
583
584
585
586
587
588
589
590
591

592
593
594
595
596
597
598
599
600
601
602
603
604
605

606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629

630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651

652
653
654
655
656
657
658
659
660
    running on workstations is for atomic write to be
    disabled, for the maximum page size to be set to 32768, for
    SQLITE_DEFAULT_PAGE_SIZE to be 1024, and for the
    maximum default page size to be set to 8192.  ^(The default xSectorSize
    method on workstation implementations always reports a sector size
    of 512 bytes.  Hence, 
    the default page size chosen by SQLite is usually 1024 bytes.)^</p>
</li>


<tcl>Subsection max_page_count</tcl>
<li><p>^(<b>PRAGMA max_page_count;
       <br>PRAGMA max_page_count = </b><i>N</i><b>;</b></p>
    <p>Query or set the maximum number of pages in the database file.)^
    ^Both forms of the pragma return the maximum page count.  ^The second
    form attempts to modify the maximum page count.  ^The maximum page
    count cannot be reduced below the current database size.
    </p>
</li>


<tcl>Subsection read_uncommitted</tcl>
<li><p>^(<b>PRAGMA read_uncommitted;
       <br>PRAGMA read_uncommitted = </b><i>boolean</i><b>;</b></p>
    <p>Query, set, or clear READ UNCOMMITTED isolation.)^ ^The default isolation
    level for SQLite is SERIALIZABLE.  ^Any process or thread can select
    READ UNCOMMITTED isolation, but SERIALIZABLE will still be used except
    between connections that share a common page and schema cache.
    Cache sharing is enabled using the [sqlite3_enable_shared_cache()] API.
    Cache sharing is disabled by default.
    </p>

    <p>See [SQLite Shared-Cache Mode] for additional information.</p>
</li>


<tcl>Subsection recursive_triggers</tcl>
<li><p>^(<b>PRAGMA recursive_triggers;
       <br>PRAGMA recursive_triggers = </b><i>boolean</i><b>;</b></p>
    <p>Query, set, or clear the recursive trigger capability.)^

    <p>^Changing the recursive_triggers setting affects the execution of
       all statements prepared
       using the database connection, including those prepared before the
       setting was changed. ^Any existing statements prepared using the legacy 
       [sqlite3_prepare()] interface may fail with an [SQLITE_SCHEMA] error
       after the recursive_triggers setting is changed.

    <p>Prior to SQLite version 3.6.18, recursive triggers were not
    supported.  The behavior of SQLite was always as if this pragma was
    set to OFF.  Support for recursive triggers was added in version 3.6.18
    but was initially turned OFF by default, for compatibility.  Recursive
    triggers may be turned on by default in future versions of SQLite.
    </p>

    <p>^(The depth of recursion for triggers has a hard upper limit set by
    the [SQLITE_MAX_TRIGGER_DEPTH] compile-time option and a run-time
    limit set by [sqlite3_limit](db,[SQLITE_LIMIT_TRIGGER_DEPTH],...).)^</p>
</li>


<tcl>Subsection reverse_unordered_selects</tcl>
<li><p>^(<b>PRAGMA reverse_unordered_selects;
       <br>PRAGMA reverse_unordered_selects = </b><i>boolean</i><b>;</b>)^</p>
    <p>^When enabled, this PRAGMA causes [SELECT] statements without a
    an ORDER BY clause to emit their results in the reverse order of what
    they normally would.  This can help debug applications that are
    making invalid assumptions about the result order.<p>SQLite makes no
    guarantees about the order of results if a SELECT omits the ORDER BY
    clause.  Even so, the order of results does not change from one
    run to the next, and so many applications mistakenly come to depend
    on the arbitrary output order whatever that order happens to be.  However, 
    sometimes new versions of SQLite will contain optimizer enhancements
    that will cause the output order of queries without ORDER BY clauses
    to shift.  When that happens, applications that depend on a certain
    output order might malfunction.  By running the application multiple
    times with this pragma both disabled and enabled, cases where the
    application makes faulty assumptions about output order can be
    identified and fixed early, reducing problems
    that might be caused by linking against a different version of SQLite.
    </p>
</li>


<tcl>Subsection secure_delete</tcl>
<li><p>^(<b>PRAGMA secure_delete;
       <br>PRAGMA </b><i>database</i><b>.secure_delete;
       <br>PRAGMA secure_delete = </b><i>boolean</i><b>
       <br>PRAGMA </b><i>database</i><b>.secure_delete =
               </b><i>boolean</i></p>
    <p>Query or change the secure-delete setting.)^ ^When secure-delete
    on, SQLite overwrites deleted content with zeros.  ^The default
    setting is determined by the [SQLITE_SECURE_DELETE]







<
|
>
|
|






<
|
>
|
|










<
|
>
|
|




















<
|
>
|
|


















<
|
>
|
|







569
570
571
572
573
574
575

576
577
578
579
580
581
582
583
584
585

586
587
588
589
590
591
592
593
594
595
596
597
598
599

600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623

624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645

646
647
648
649
650
651
652
653
654
655
656
    running on workstations is for atomic write to be
    disabled, for the maximum page size to be set to 32768, for
    SQLITE_DEFAULT_PAGE_SIZE to be 1024, and for the
    maximum default page size to be set to 8192.  ^(The default xSectorSize
    method on workstation implementations always reports a sector size
    of 512 bytes.  Hence, 
    the default page size chosen by SQLite is usually 1024 bytes.)^</p>

}

Pragma max_page_count {
    <p>^(<b>PRAGMA max_page_count;
       <br>PRAGMA max_page_count = </b><i>N</i><b>;</b></p>
    <p>Query or set the maximum number of pages in the database file.)^
    ^Both forms of the pragma return the maximum page count.  ^The second
    form attempts to modify the maximum page count.  ^The maximum page
    count cannot be reduced below the current database size.
    </p>

}

Pragma read_uncommitted {
    <p>^(<b>PRAGMA read_uncommitted;
       <br>PRAGMA read_uncommitted = </b><i>boolean</i><b>;</b></p>
    <p>Query, set, or clear READ UNCOMMITTED isolation.)^ ^The default isolation
    level for SQLite is SERIALIZABLE.  ^Any process or thread can select
    READ UNCOMMITTED isolation, but SERIALIZABLE will still be used except
    between connections that share a common page and schema cache.
    Cache sharing is enabled using the [sqlite3_enable_shared_cache()] API.
    Cache sharing is disabled by default.
    </p>

    <p>See [SQLite Shared-Cache Mode] for additional information.</p>

}

Pragma recursive_triggers {
    <p>^(<b>PRAGMA recursive_triggers;
       <br>PRAGMA recursive_triggers = </b><i>boolean</i><b>;</b></p>
    <p>Query, set, or clear the recursive trigger capability.)^

    <p>^Changing the recursive_triggers setting affects the execution of
       all statements prepared
       using the database connection, including those prepared before the
       setting was changed. ^Any existing statements prepared using the legacy 
       [sqlite3_prepare()] interface may fail with an [SQLITE_SCHEMA] error
       after the recursive_triggers setting is changed.

    <p>Prior to SQLite version 3.6.18, recursive triggers were not
    supported.  The behavior of SQLite was always as if this pragma was
    set to OFF.  Support for recursive triggers was added in version 3.6.18
    but was initially turned OFF by default, for compatibility.  Recursive
    triggers may be turned on by default in future versions of SQLite.
    </p>

    <p>^(The depth of recursion for triggers has a hard upper limit set by
    the [SQLITE_MAX_TRIGGER_DEPTH] compile-time option and a run-time
    limit set by [sqlite3_limit](db,[SQLITE_LIMIT_TRIGGER_DEPTH],...).)^</p>

}

Pragma reverse_unordered_selects {
    <p>^(<b>PRAGMA reverse_unordered_selects;
       <br>PRAGMA reverse_unordered_selects = </b><i>boolean</i><b>;</b>)^</p>
    <p>^When enabled, this PRAGMA causes [SELECT] statements without a
    an ORDER BY clause to emit their results in the reverse order of what
    they normally would.  This can help debug applications that are
    making invalid assumptions about the result order.<p>SQLite makes no
    guarantees about the order of results if a SELECT omits the ORDER BY
    clause.  Even so, the order of results does not change from one
    run to the next, and so many applications mistakenly come to depend
    on the arbitrary output order whatever that order happens to be.  However, 
    sometimes new versions of SQLite will contain optimizer enhancements
    that will cause the output order of queries without ORDER BY clauses
    to shift.  When that happens, applications that depend on a certain
    output order might malfunction.  By running the application multiple
    times with this pragma both disabled and enabled, cases where the
    application makes faulty assumptions about output order can be
    identified and fixed early, reducing problems
    that might be caused by linking against a different version of SQLite.
    </p>

}

Pragma secure_delete {
    <p>^(<b>PRAGMA secure_delete;
       <br>PRAGMA </b><i>database</i><b>.secure_delete;
       <br>PRAGMA secure_delete = </b><i>boolean</i><b>
       <br>PRAGMA </b><i>database</i><b>.secure_delete =
               </b><i>boolean</i></p>
    <p>Query or change the secure-delete setting.)^ ^When secure-delete
    on, SQLite overwrites deleted content with zeros.  ^The default
    setting is determined by the [SQLITE_SECURE_DELETE]
668
669
670
671
672
673
674
675
676

677
678
679
680
681
682
683
684
685

686
687
688
689
690
691
692
693
694
    of the main database at the time the ATTACH command is evaluated.

    <p>
    ^When multiple database connections share the same cache, changing
    the secure-delete flag on one database connection changes it for them
    all.
    </p>
</li>


<tcl>Subsection short_column_names</tcl>
<li><p>^(<b>PRAGMA short_column_names;
       <br>PRAGMA short_column_names = </b><i>boolean</i><b>;</b></p>
    <p>Query or change the short-column-names flag.)^ ^This flag affects
    the way SQLite names columns of data returned by [SELECT] statements.
    See the [full_column_names] pragma for full details.
    </p>
</li>


<tcl>Subsection synchronous</tcl>
<li><p>^(<b>PRAGMA synchronous;
       <br>PRAGMA synchronous = </b>
          <i>0 | OFF | 1 | NORMAL | 2 | FULL</i><b>;</b></p>

    <p>Query or change the setting of the "synchronous" flag.)^
    ^The first (query) form will return the synchronous setting as an 
    integer.  ^When synchronous is FULL (2), the SQLite database engine will
    pause at critical moments to make sure that data has actually been 







<
|
>
|
|





<
|
>
|
|







664
665
666
667
668
669
670

671
672
673
674
675
676
677
678
679

680
681
682
683
684
685
686
687
688
689
690
    of the main database at the time the ATTACH command is evaluated.

    <p>
    ^When multiple database connections share the same cache, changing
    the secure-delete flag on one database connection changes it for them
    all.
    </p>

}

LegacyPragma short_column_names {
    <p>^(<b>PRAGMA short_column_names;
       <br>PRAGMA short_column_names = </b><i>boolean</i><b>;</b></p>
    <p>Query or change the short-column-names flag.)^ ^This flag affects
    the way SQLite names columns of data returned by [SELECT] statements.
    See the [full_column_names] pragma for full details.
    </p>

}

Pragma synchronous {
    <p>^(<b>PRAGMA synchronous;
       <br>PRAGMA synchronous = </b>
          <i>0 | OFF | 1 | NORMAL | 2 | FULL</i><b>;</b></p>

    <p>Query or change the setting of the "synchronous" flag.)^
    ^The first (query) form will return the synchronous setting as an 
    integer.  ^When synchronous is FULL (2), the SQLite database engine will
    pause at critical moments to make sure that data has actually been 
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
    the database might become corrupted if the operating system
    crashes or the computer loses power before that data has been written
    to the disk surface.  On the other hand, some
    operations are as much as 50 or more times faster with synchronous OFF.
    </p>
    <p>^The default setting is synchronous=FULL.
    </p>
</li>


<tcl>Subsection temp_store</tcl>
<li><p>^(<b>PRAGMA temp_store;
       <br>PRAGMA temp_store = </b>
            <i>0 | DEFAULT | 1 | FILE | 2 | MEMORY</i><b>;</b></p>

    <p>Query or change the setting of the "<b>temp_store</b>" parameter.)^
    ^When temp_store is DEFAULT (0), the compile-time C preprocessor macro
    [SQLITE_TEMP_STORE] is used to determine where temporary tables and indices
    are stored.  ^When







<
|

|
|







705
706
707
708
709
710
711

712
713
714
715
716
717
718
719
720
721
722
    the database might become corrupted if the operating system
    crashes or the computer loses power before that data has been written
    to the disk surface.  On the other hand, some
    operations are as much as 50 or more times faster with synchronous OFF.
    </p>
    <p>^The default setting is synchronous=FULL.
    </p>

}

Pragma temp_store {
    <p>^(<b>PRAGMA temp_store;
       <br>PRAGMA temp_store = </b>
            <i>0 | DEFAULT | 1 | FILE | 2 | MEMORY</i><b>;</b></p>

    <p>Query or change the setting of the "<b>temp_store</b>" parameter.)^
    ^When temp_store is DEFAULT (0), the compile-time C preprocessor macro
    [SQLITE_TEMP_STORE] is used to determine where temporary tables and indices
    are stored.  ^When
767
768
769
770
771
772
773
774
775
776

777
778
779
780
781
782
783
784
785
        <td align="center">2</td>
        <td align="center">memory</td></tr>
    <tr><td align="center">3</td>
        <td align="center"><em>any</em></td>
        <td align="center">memory</td></tr>
    </table>
    </blockquote>)^
    </li>
    <br>


<tcl>Subsection temp_store_directory</tcl>
<li><p>^(<b>PRAGMA temp_store_directory;
       <br>PRAGMA temp_store_directory = '</b><i>directory-name</i><b>';</b></p>
    <p>Query or change the setting of the "temp_store_directory" - the
    directory where files used for storing [temporary tables] and indices
    are kept.</p>)^

    <p>^When the temp_store_directory setting is changed, all existing temporary
    tables, indices, triggers, and viewers are immediately deleted.  In







<
<
|
>
|
|







762
763
764
765
766
767
768


769
770
771
772
773
774
775
776
777
778
779
        <td align="center">2</td>
        <td align="center">memory</td></tr>
    <tr><td align="center">3</td>
        <td align="center"><em>any</em></td>
        <td align="center">memory</td></tr>
    </table>
    </blockquote>)^


}

LegacyPragma temp_store_directory {
    <p>^(<b>PRAGMA temp_store_directory;
       <br>PRAGMA temp_store_directory = '</b><i>directory-name</i><b>';</b></p>
    <p>Query or change the setting of the "temp_store_directory" - the
    directory where files used for storing [temporary tables] and indices
    are kept.</p>)^

    <p>^When the temp_store_directory setting is changed, all existing temporary
    tables, indices, triggers, and viewers are immediately deleted.  In
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816

817
818
819
820
821
822
823
824
825

826
827
828
829
830

831
832
833
834
835
836
837

838
839
840
841

842
843
844
845
846
847
848

849
850
851
852

853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
    error is raised if <i>directory-name</i> is not found or is not
    writable. </p>

    <p>The default directory for temporary files depends on the OS.  Some
    OS interfaces may choose to ignore this variable in place temporary
    files in some other directory different from the directory specified
    here.  In that sense, this pragma is only advisory.</p>
    </li>
</ul>

<tcl>Section {Pragmas to query the database schema} schema</tcl>

<ul>
<tcl>Subsection collation_list</tcl>
<li><p>^(<b>PRAGMA collation_list;</b></p>
    <p>Return a list of the collating sequences defined for the current
    database connection.</p>)^</li>


<tcl>Subsection database_list</tcl>
<li><p>^(<b>PRAGMA database_list;</b></p>
    <p>This pragma works like a query to return one row for each database
    attached to the current database connection.)^
    ^(Columns of the result set include the index and 
    the name the database was attached with.)^  ^The first row will be for 
    the main database.  ^The second row will be for the database used to 
    store temporary tables.</p></li>


<tcl>Subsection foreign_key_list</tcl>
<li><p>^(<b>PRAGMA foreign_key_list(</b><i>table-name</i><b>);</b></p>
    <p>This pragma returns one rwo for each foreign key that references
    a column in the argument table.)^</li>


<tcl>Subsection freelist_count</tcl>
<li><p>^(<b>PRAGMA freelist_count;</b></p>
    <p>Return the number of unused pages in the database file.)^ ^Running
    a <a href="#pragma_incremental_vacuum">"PRAGMA incremental_vaccum(N);"</a> 
    command with a large value of N will shrink the database file by this
    number of pages when incremental vacuum is enabled. </p></li>


<tcl>Subsection index_info</tcl>
<li><p>^(<b>PRAGMA index_info(</b><i>index-name</i><b>);</b></p>
    <p>This program returns one row row each column in the named index.</p>)^


<tcl>Subsection index_list</tcl>
<li><p>^(<b>PRAGMA index_list(</b><i>table-name</i><b>);</b></p>
    <p>This pragma returns one row for each index associated with the
    given table.)^   ^Columns of the result set include the
    index name and a flag to indicate whether or not the index is UNIQUE.
    </p></li>


<tcl>Subsection page_count</tcl>
<li><p>^(<b>PRAGMA page_count;</b></p>
    <p>Return the total number of pages in the database file.</p>)^</li>


<tcl>Subsection table_info</tcl>
<li><p>^(<b>PRAGMA table_info(</b><i>table-name</i><b>);</b></p>
    <p>This pragma returns one row for each column in the named table.)^
    ^Columns in the result set include the column name,
    data type, whether or not the column can be NULL, and the default
    value for the column.</p></li>
</ul>

<tcl>Section {Pragmas to query/modify version values} version</tcl>

<ul>
<tcl>Subsection schema_version user_version</tcl>
<li><p><b>PRAGMA schema_version; 
       <br>PRAGMA schema_version = </b><i>integer </i><b>;
       <br>PRAGMA user_version;
       <br>PRAGMA user_version = </b><i>integer </i><b>;</b>

  
<p>    ^The pragmas schema_version and user_version are used to set or get
       the value of the schema-version and user-version, respectively. ^Both







<
<
|
<

<
|
|

|
|
>
|
|





|
|
>
|
|

|
|
>
|
|



|
|
>
|
|

|
>
|
|



|
|
>
|
|
|
|
>
|
|



|
<
|
<

<
|
|







793
794
795
796
797
798
799


800

801

802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855

856

857

858
859
860
861
862
863
864
865
866
    error is raised if <i>directory-name</i> is not found or is not
    writable. </p>

    <p>The default directory for temporary files depends on the OS.  Some
    OS interfaces may choose to ignore this variable in place temporary
    files in some other directory different from the directory specified
    here.  In that sense, this pragma is only advisory.</p>


}



Pragma collation_list {
    <p>^(<b>PRAGMA collation_list;</b></p>
    <p>Return a list of the collating sequences defined for the current
    database connection.</p>)^
}

Pragma database_list {
    <p>^(<b>PRAGMA database_list;</b></p>
    <p>This pragma works like a query to return one row for each database
    attached to the current database connection.)^
    ^(Columns of the result set include the index and 
    the name the database was attached with.)^  ^The first row will be for 
    the main database.  ^The second row will be for the database used to 
    store temporary tables.</p>
}

LegacyPragma foreign_key_list {
    <p>^(<b>PRAGMA foreign_key_list(</b><i>table-name</i><b>);</b></p>
    <p>This pragma returns one rwo for each foreign key that references
    a column in the argument table.)^
}

Pragma freelist_count {
    <p>^(<b>PRAGMA freelist_count;</b></p>
    <p>Return the number of unused pages in the database file.)^ ^Running
    a <a href="#pragma_incremental_vacuum">"PRAGMA incremental_vaccum(N);"</a> 
    command with a large value of N will shrink the database file by this
    number of pages when incremental vacuum is enabled. </p>
}

Pragma index_info {
    <p>^(<b>PRAGMA index_info(</b><i>index-name</i><b>);</b></p>
    <p>This program returns one row row each column in the named index.</p>)^
}

Pragma index_list {
    <p>^(<b>PRAGMA index_list(</b><i>table-name</i><b>);</b></p>
    <p>This pragma returns one row for each index associated with the
    given table.)^   ^Columns of the result set include the
    index name and a flag to indicate whether or not the index is UNIQUE.
    </p>
}

Pragma page_count {
    <p>^(<b>PRAGMA page_count;</b></p>
    <p>Return the total number of pages in the database file.</p>)^
}

Pragma table_info {
    <p>^(<b>PRAGMA table_info(</b><i>table-name</i><b>);</b></p>
    <p>This pragma returns one row for each column in the named table.)^
    ^Columns in the result set include the column name,
    data type, whether or not the column can be NULL, and the default
    value for the column.</p>

}



Pragma {schema_version user_version} {
    <p><b>PRAGMA schema_version; 
       <br>PRAGMA schema_version = </b><i>integer </i><b>;
       <br>PRAGMA user_version;
       <br>PRAGMA user_version = </b><i>integer </i><b>;</b>

  
<p>    ^The pragmas schema_version and user_version are used to set or get
       the value of the schema-version and user-version, respectively. ^Both
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901

902
903
904
905
906
907
908
909
910
911
912
913
914

915
916
917
918
919
920
921
922
923

924
925
926
927
928
929
930
931



932

933
934
935
936
937
938
939
940





941
942
943
944
945
946
947
948
949
950





































951


























       the schema of the database against which the compiled query is actually 
       executed.  ^Subverting this mechanism by using "PRAGMA schema_version" 
       to modify the schema-version is potentially dangerous and may lead 
       to program crashes or database corruption. Use with caution!</p>
  
<p>    ^The user-version is not used internally by SQLite. It may be used by
       applications for any purpose.</p>
</li>
</ul>

<tcl>Section {Pragmas to debug the library} debug</tcl>

<ul>
<tcl>Subsection compile_options</tcl>
<li><p><b>PRAGMA compile_options;</b></p>
    <p>^This pragma returns the names of [compile-time options] used when
    building SQLite, one option per row.  ^The "SQLITE_" prefix is omitted
    from the returned option names.  See also the
    [sqlite3_compileoption_get()] C/C++ interface and the
    [sqlite_compileoption_get()] SQL functions.</p></li>


<tcl>Subsection integrity_check</tcl>
<li><p><b>PRAGMA integrity_check;
    <br>PRAGMA integrity_check(</b><i>integer</i><b>)</b></p>
    <p>^This pragma does an integrity check of the entire database.  ^It
    looks for out-of-order records, missing pages, malformed records, and
    corrupt indices.
    ^If any problems are found, then strings are returned (as multiple
    rows with a single column per row) which describe
    the problems.  ^At most <i>integer</i> errors will be reported
    before the analysis quits.  ^The default value for <i>integer</i>
    is 100.  ^If no errors are found, a single row with the value "ok" is
    returned.</p></li>


<tcl>Subsection quick_check</tcl>
<li><p><b>PRAGMA quick_check;
    <br>PRAGMA quick_check(</b><i>integer</i><b>)</b></p>
    <p>^The pragma is like [integrity_check] except that it does not verify
    that index content matches table content.  By skipping the verification
    of index content, quick_check is able to run much faster than
    integrity_check.  Otherwise the two pragmas are the same.
    </p></li>


<tcl>Subsection parser_trace</tcl>
<li><p><b>PRAGMA parser_trace = </b><i>boolean</i><b>; </b></p>

    <p>^Turn tracing of the SQL parser inside of the
    SQLite library on and off.  This is used for debugging.
    This only works if the library is compiled with the SQLITE_DEBUG
    compile-time option.
    </p></li>





<tcl>Subsection vdbe_trace</tcl>
<li><p><b>PRAGMA vdbe_trace = </b><i>boolean</i><b>;</b></p>

    <p>^Turn tracing of the virtual database engine inside of the
    SQLite library on and off.  This is used for debugging.  See the 
    <a href="vdbe.html#trace">VDBE documentation</a> for more 
    information.</p></li>






<tcl>Subsection vdbe_listing</tcl>
<li><p><b>PRAGMA vdbe_listing = </b><i>boolean</i><b>;</b></p>

    <p>^Turn listings of virtual machine programs on and off.
    With listing is on, the entire content of a program is printed
    just prior to beginning execution.  The statement
    executes normally after the listing is printed.
    This is used for debugging.  See the 
    <a href="vdbe.html#trace">VDBE documentation</a> for more 
    information.</p></li>





































</ul>

































<
<
|
<

<
|
|




|
|
>
|
|









|
|
>
|
|





|
|
>
|
|




|
|
>
>
>
|
>
|
|




|

>
>
>
>
>
|
|







|
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
|
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
875
876
877
878
879
880
881


882

883

884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
       the schema of the database against which the compiled query is actually 
       executed.  ^Subverting this mechanism by using "PRAGMA schema_version" 
       to modify the schema-version is potentially dangerous and may lead 
       to program crashes or database corruption. Use with caution!</p>
  
<p>    ^The user-version is not used internally by SQLite. It may be used by
       applications for any purpose.</p>


}



Pragma compile_options {
    <p><b>PRAGMA compile_options;</b></p>
    <p>^This pragma returns the names of [compile-time options] used when
    building SQLite, one option per row.  ^The "SQLITE_" prefix is omitted
    from the returned option names.  See also the
    [sqlite3_compileoption_get()] C/C++ interface and the
    [sqlite_compileoption_get()] SQL functions.</p>
}

Pragma integrity_check {
    <p><b>PRAGMA integrity_check;
    <br>PRAGMA integrity_check(</b><i>integer</i><b>)</b></p>
    <p>^This pragma does an integrity check of the entire database.  ^It
    looks for out-of-order records, missing pages, malformed records, and
    corrupt indices.
    ^If any problems are found, then strings are returned (as multiple
    rows with a single column per row) which describe
    the problems.  ^At most <i>integer</i> errors will be reported
    before the analysis quits.  ^The default value for <i>integer</i>
    is 100.  ^If no errors are found, a single row with the value "ok" is
    returned.</p>
}

Pragma quick_check {
    <p><b>PRAGMA quick_check;
    <br>PRAGMA quick_check(</b><i>integer</i><b>)</b></p>
    <p>^The pragma is like [integrity_check] except that it does not verify
    that index content matches table content.  By skipping the verification
    of index content, quick_check is able to run much faster than
    integrity_check.  Otherwise the two pragmas are the same.
    </p>
}

Pragma parser_trace {
    <p><b>PRAGMA parser_trace = </b><i>boolean</i><b>; </b></p>

    <p>^Turn tracing of the SQL parser inside of the
    SQLite library on and off.  This is used for debugging.
    This only works if the library is compiled with the SQLITE_DEBUG
    compile-time option.</p>

    <p>This PRAGMA is used to help test and debug the SQLite library
    itself.  It is of little or not use to applications and is disabled
    if SQLite is not compiled with [SQLITE_DEBUG].</p>
}

Pragma vdbe_trace {
    <p><b>PRAGMA vdbe_trace = </b><i>boolean</i><b>;</b></p>

    <p>^Turn tracing of the virtual database engine inside of the
    SQLite library on and off.  This is used for debugging.  See the 
    <a href="vdbe.html#trace">VDBE documentation</a> for more 
    information.</p>

    <p>This PRAGMA is used to help test and debug the SQLite library
    itself.  It is of little or not use to applications and is disabled
    if SQLite is not compiled with [SQLITE_DEBUG].</p>
}

Pragma vdbe_listing {
    <p><b>PRAGMA vdbe_listing = </b><i>boolean</i><b>;</b></p>

    <p>^Turn listings of virtual machine programs on and off.
    With listing is on, the entire content of a program is printed
    just prior to beginning execution.  The statement
    executes normally after the listing is printed.
    This is used for debugging.  See the 
    <a href="vdbe.html#trace">VDBE documentation</a> for more 
    information.</p>

    <p>This PRAGMA is used to help test and debug the SQLite library
    itself.  It is of little or not use to applications and is disabled
    if SQLite is not compiled with [SQLITE_DEBUG].</p>
}

Pragma wal_checkpoint {
    <p><b>PRAGMA </b><i>database</i><b>.wal_checkpoint;</b></p>

    <p>^If the [write-ahead log] is enabled (via the [journal_mode pragma]),
    this pragma causes a checkpoint operation to run on database
    <i>database</i>, or on all attached databases if <i>database</i>
    is omitted.  ^If [write-ahead log] is disabled, this pragma is a
    harmless no-op.</p>

    <p>^Invoking this pragma is equivalent to calling the
    [sqlite3_wal_checkpoint()] C interface.</p>

}

Pragma wal_autocheckpoint {
    <p><b>PRAGMA wal_autocheckpoint;<br>
     PRAGMA wal_autocheckpoint=</b><i>N</i><b>;</b></p>

    <p>^This pragma queries or sets the [write-ahead log] auto-checkpoint
    interval.  When the [write-ahead log] is enabled (via the
    [journal_mode pragma]) a checkpoint will be run automatically whenever
    the write-ahead log equals or exceeds <i>N</i> pages in length.
    Setting the auto-checkpoint size to zero or a negative value
    turns auto-checkpointing off.</p>
    
    <p>^This pragma is a wrapper around the
    [sqlite3_wal_autocheckpoint()] C interface.</p>

}

Section {List Of PRAGMAs} {toc} {{pragma list}}
</tcl>
<table border=0 width="100%" cellpadding=10>
<tr><td valign="top" align="left"><ul>
<tcl>
set allprag [lsort [array names PragmaRef]]
set nprag [llength $allprag]
set nrow [expr {($nprag+2)/3}]
for {set i 0} {$i<$nprag} {incr i} {
  set prag [lindex $allprag $i]
  hd_puts "<li><a href=\"#pragma_$prag\">$prag</a>\n"
  if {$i%$nrow==($nrow-1) && $i+1<$nprag} {
    hd_puts "</ul></td><td valign=\"top\" align=\"left\"><ul>\n"
  }
}
</tcl>
</ul></td></tr></table>
<tcl>
foreach prag [lsort [array names PragmaBody]] {
  hd_fragment pragma_$prag
  foreach x $PragmaKeys($prag) {
    hd_keywords *$x "PRAGMA $x" "$x pragma"
  }
  hd_puts "<hr>"
  hd_resolve $PragmaBody($prag)
}
</tcl>
<hr>
Changes to pages/sitemap.in.
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
<li> <a href="different.html">Distinctive Features</a> </li>
<li> <a href="doclist.html">Alphabetical list of docs</a> </li>
<li> <a href="books.html">Books About SQLite</a> </li>
<li> <a href="keyword_index.html">Website Keyword Index</a> </li>
</ul><td valign=top><ul>
<li> <a href="lang.html">SQL Syntax</a>
<ul>
<li> <a href="pragma.html">Pragmas</a>
<li> <a href="lang_corefunc.html">SQL functions</a>
<li> <a href="lang_datefunc.html">Date &amp; time functions</a>
<li> <a href="lang_aggfunc.html">Aggregate functions</a>
</ul>
<li> <a href="c3ref/intro.html">C/C++ Interface Spec</a>
<ul>
<li> <a href="cintro.html">Introduction</a>







|







12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
<li> <a href="different.html">Distinctive Features</a> </li>
<li> <a href="doclist.html">Alphabetical list of docs</a> </li>
<li> <a href="books.html">Books About SQLite</a> </li>
<li> <a href="keyword_index.html">Website Keyword Index</a> </li>
</ul><td valign=top><ul>
<li> <a href="lang.html">SQL Syntax</a>
<ul>
<li> <a href="pragma.html#toc">Pragmas</a>
<li> <a href="lang_corefunc.html">SQL functions</a>
<li> <a href="lang_datefunc.html">Date &amp; time functions</a>
<li> <a href="lang_aggfunc.html">Aggregate functions</a>
</ul>
<li> <a href="c3ref/intro.html">C/C++ Interface Spec</a>
<ul>
<li> <a href="cintro.html">Introduction</a>
Changes to pages/wal.in.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<title>Write-Ahead Logging</title>
<tcl>hd_keywords {WAL} {write-ahead log}</tcl>

<h1 align="center">Write-Ahead Logging</h1>

<p>The default method in which SQLite implements
[atomic commit | atomic commit and rollback] is through the use of
a [rollback journal].
Beginning with [SQLite version 3.7.0], a new write-ahead log option
(hereafter referred to as "WAL")
for implementing atomic commit and rollback is available as an option
on some platforms.</p>

<p>There are advantages and disadvantages to using WAL.  We begin with
a quick summary of advantages:</p>









|







1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<title>Write-Ahead Logging</title>
<tcl>hd_keywords {WAL} {write-ahead log}</tcl>

<h1 align="center">Write-Ahead Logging</h1>

<p>The default method in which SQLite implements
[atomic commit | atomic commit and rollback] is through the use of
a [rollback journal].
Beginning with [version 3.7.0], a new write-ahead log option
(hereafter referred to as "WAL")
for implementing atomic commit and rollback is available as an option
on some platforms.</p>

<p>There are advantages and disadvantages to using WAL.  We begin with
a quick summary of advantages:</p>