diff options
Diffstat (limited to 'libraries/sqlite/unix/sqlite-3.5.1/www/pragma.tcl')
-rw-r--r-- | libraries/sqlite/unix/sqlite-3.5.1/www/pragma.tcl | 635 |
1 files changed, 635 insertions, 0 deletions
diff --git a/libraries/sqlite/unix/sqlite-3.5.1/www/pragma.tcl b/libraries/sqlite/unix/sqlite-3.5.1/www/pragma.tcl new file mode 100644 index 0000000..d1fcb21 --- /dev/null +++ b/libraries/sqlite/unix/sqlite-3.5.1/www/pragma.tcl | |||
@@ -0,0 +1,635 @@ | |||
1 | # | ||
2 | # Run this Tcl script to generate the pragma.html file. | ||
3 | # | ||
4 | set rcsid {$Id: pragma.tcl,v 1.28 2007/08/28 08:19:49 danielk1977 Exp $} | ||
5 | source common.tcl | ||
6 | header {Pragma statements supported by SQLite} | ||
7 | |||
8 | proc Section {name {label {}}} { | ||
9 | puts "\n<hr />" | ||
10 | if {$label!=""} { | ||
11 | puts "<a name=\"$label\"></a>" | ||
12 | } | ||
13 | puts "<h1>$name</h1>\n" | ||
14 | } | ||
15 | |||
16 | puts { | ||
17 | <p>The <a href="#syntax">PRAGMA command</a> is a special command used to | ||
18 | modify the operation of the SQLite library or to query the library for | ||
19 | internal (non-table) data. The PRAGMA command is issued using the same | ||
20 | interface as other SQLite commands (e.g. SELECT, INSERT) but is | ||
21 | different in the following important respects: | ||
22 | </p> | ||
23 | <ul> | ||
24 | <li>Specific pragma statements may be removed and others added in future | ||
25 | releases of SQLite. Use with caution! | ||
26 | <li>No error messages are generated if an unknown pragma is issued. | ||
27 | Unknown pragmas are simply ignored. This means if there is a typo in | ||
28 | a pragma statement the library does not inform the user of the fact. | ||
29 | <li>Some pragmas take effect during the SQL compilation stage, not the | ||
30 | execution stage. This means if using the C-language sqlite3_prepare(), | ||
31 | sqlite3_step(), sqlite3_finalize() API (or similar in a wrapper | ||
32 | interface), the pragma may be applied to the library during the | ||
33 | sqlite3_prepare() call. | ||
34 | <li>The pragma command is unlikely to be compatible with any other SQL | ||
35 | engine. | ||
36 | </ul> | ||
37 | |||
38 | <p>The available pragmas fall into four basic categories:</p> | ||
39 | <ul> | ||
40 | <li>Pragmas used to <a href="#modify">modify the operation</a> of the | ||
41 | SQLite library in some manner, or to query for the current mode of | ||
42 | operation. | ||
43 | <li>Pragmas used to <a href="#schema">query the schema</a> of the current | ||
44 | database. | ||
45 | <li>Pragmas used to <a href="#version">query or modify the databases two | ||
46 | version values</a>, the schema-version and the user-version. | ||
47 | <li>Pragmas used to <a href="#debug">debug the library</a> and verify that | ||
48 | database files are not corrupted. | ||
49 | </ul> | ||
50 | } | ||
51 | |||
52 | Section {PRAGMA command syntax} syntax | ||
53 | |||
54 | Syntax {sql-statement} { | ||
55 | PRAGMA <name> [= <value>] | | ||
56 | PRAGMA <function>(<arg>) | ||
57 | } | ||
58 | |||
59 | puts { | ||
60 | <p>The pragmas that take an integer <b><i>value</i></b> also accept | ||
61 | symbolic names. The strings "<b>on</b>", "<b>true</b>", and "<b>yes</b>" | ||
62 | are equivalent to <b>1</b>. The strings "<b>off</b>", "<b>false</b>", | ||
63 | and "<b>no</b>" are equivalent to <b>0</b>. These strings are case- | ||
64 | insensitive, and do not require quotes. An unrecognized string will be | ||
65 | treated as <b>1</b>, and will not generate an error. When the <i>value</i> | ||
66 | is returned it is as an integer.</p> | ||
67 | } | ||
68 | |||
69 | Section {Pragmas to modify library operation} modify | ||
70 | |||
71 | puts { | ||
72 | <ul> | ||
73 | <a name="pragma_auto_vacuum"></a> | ||
74 | <li><p><b>PRAGMA auto_vacuum;<br> | ||
75 | PRAGMA auto_vacuum = </b> | ||
76 | <i>0 | none | 1 | full | 2 | incremental</i><b>;</b></p> | ||
77 | <p>Query or set the auto-vacuum flag in the database.</p> | ||
78 | |||
79 | <p>Normally, (that is to say when auto_vacuum is 0 or "none") | ||
80 | when a transaction that deletes data from a database is | ||
81 | committed, the database file remains the same size. Unused database file | ||
82 | pages are added to a "freelist" are reused for subsequent inserts. The | ||
83 | database file does not shrink. | ||
84 | In this mode the <a href="lang_vacuum.html">VACUUM</a> | ||
85 | command can be used to reclaim unused space.</p> | ||
86 | |||
87 | <p>When the auto-vacuum flag is 1 (full), the freelist pages are | ||
88 | moved to the end of the file and the file is truncated to remove | ||
89 | the freelist pages at every commit. | ||
90 | Note, however, that auto-vacuum only truncates the freelist pages | ||
91 | from the file. Auto-vacuum does not defragment the database nor | ||
92 | repack individual database pages the way that the | ||
93 | <a href="lang_vacuum.html">VACUUM</a> command does. In fact, because | ||
94 | it moves pages around within the file, auto-vacuum can actually | ||
95 | make fragmentation worse.</p> | ||
96 | |||
97 | <p>Auto-vacuuming is only possible if the database stores some | ||
98 | additional information that allows each database page to be | ||
99 | traced backwards to its referer. Therefore, auto-vacuuming must | ||
100 | be turned on before any tables are created. It is not possible | ||
101 | to enable or disable auto-vacuum after a table has been created.</p> | ||
102 | |||
103 | <p>When the value of auto-vacuum is 2 (incremental) then the additional | ||
104 | information needed to do autovacuuming is stored in the database file | ||
105 | but autovacuuming does not occur automatically at each commit as it | ||
106 | does with auto_vacuum==full. In incremental mode, the separate | ||
107 | <a href="#pragma_incremental_vacuum">incremental_vacuum</a> pragma must | ||
108 | be invoked to cause the vacuum to occur.</p> | ||
109 | |||
110 | <p>The database connection can be changed between full and incremental | ||
111 | autovacuum mode at will. However, the connection cannot be changed | ||
112 | in and out of the "none" mode after any table has been created in the | ||
113 | database. | ||
114 | </p></li> | ||
115 | |||
116 | <a name="pragma_cache_size"></a> | ||
117 | <li><p><b>PRAGMA cache_size; | ||
118 | <br>PRAGMA cache_size = </b><i>Number-of-pages</i><b>;</b></p> | ||
119 | <p>Query or change the maximum number of database disk pages that SQLite | ||
120 | will hold in memory at once. Each page uses about 1.5K of memory. | ||
121 | The default cache size is 2000. If you are doing UPDATEs or DELETEs | ||
122 | that change many rows of a database and you do not mind if SQLite | ||
123 | uses more memory, you can increase the cache size for a possible speed | ||
124 | improvement.</p> | ||
125 | <p>When you change the cache size using the cache_size pragma, the | ||
126 | change only endures for the current session. The cache size reverts | ||
127 | to the default value when the database is closed and reopened. Use | ||
128 | the <a href="#pragma_default_cache_size"><b>default_cache_size</b></a> | ||
129 | pragma to check the cache size permanently.</p></li> | ||
130 | |||
131 | <a name="pragma_case_sensitive_like"></a> | ||
132 | <li><p><b>PRAGMA case_sensitive_like; | ||
133 | <br>PRAGMA case_sensitive_like = </b><i>0 | 1</i><b>;</b></p> | ||
134 | <p>The default behavior of the LIKE operator is to ignore case | ||
135 | for latin1 characters. Hence, by default <b>'a' LIKE 'A'</b> is | ||
136 | true. The case_sensitive_like pragma can be turned on to change | ||
137 | this behavior. When case_sensitive_like is enabled, | ||
138 | <b>'a' LIKE 'A'</b> is false but <b>'a' LIKE 'a'</b> is still true.</p> | ||
139 | </li> | ||
140 | |||
141 | <a name="pragma_count_changes"></a> | ||
142 | <li><p><b>PRAGMA count_changes; | ||
143 | <br>PRAGMA count_changes = </b><i>0 | 1</i><b>;</b></p> | ||
144 | <p>Query or change the count-changes flag. Normally, when the | ||
145 | count-changes flag is not set, INSERT, UPDATE and DELETE statements | ||
146 | return no data. When count-changes is set, each of these commands | ||
147 | returns a single row of data consisting of one integer value - the | ||
148 | number of rows inserted, modified or deleted by the command. The | ||
149 | returned change count does not include any insertions, modifications | ||
150 | or deletions performed by triggers.</p> | ||
151 | |||
152 | <a name="pragma_default_cache_size"></a> | ||
153 | <li><p><b>PRAGMA default_cache_size; | ||
154 | <br>PRAGMA default_cache_size = </b><i>Number-of-pages</i><b>;</b></p> | ||
155 | <p>Query or change the maximum number of database disk pages that SQLite | ||
156 | will hold in memory at once. Each page uses 1K on disk and about | ||
157 | 1.5K in memory. | ||
158 | This pragma works like the | ||
159 | <a href="#pragma_cache_size"><b>cache_size</b></a> | ||
160 | pragma with the additional | ||
161 | feature that it changes the cache size persistently. With this pragma, | ||
162 | you can set the cache size once and that setting is retained and reused | ||
163 | every time you reopen the database.</p></li> | ||
164 | |||
165 | <a name="pragma_default_synchronous"></a> | ||
166 | <li><p><b>PRAGMA default_synchronous;</b></p> | ||
167 | <p>This pragma was available in version 2.8 but was removed in version | ||
168 | 3.0. It is a dangerous pragma whose use is discouraged. To help | ||
169 | dissuide users of version 2.8 from employing this pragma, the documentation | ||
170 | will not tell you what it does.</p></li> | ||
171 | |||
172 | |||
173 | <a name="pragma_empty_result_callbacks"></a> | ||
174 | <li><p><b>PRAGMA empty_result_callbacks; | ||
175 | <br>PRAGMA empty_result_callbacks = </b><i>0 | 1</i><b>;</b></p> | ||
176 | <p>Query or change the empty-result-callbacks flag.</p> | ||
177 | <p>The empty-result-callbacks flag affects the sqlite3_exec API only. | ||
178 | Normally, when the empty-result-callbacks flag is cleared, the | ||
179 | callback function supplied to the sqlite3_exec() call is not invoked | ||
180 | for commands that return zero rows of data. When empty-result-callbacks | ||
181 | is set in this situation, the callback function is invoked exactly once, | ||
182 | with the third parameter set to 0 (NULL). This is to enable programs | ||
183 | that use the sqlite3_exec() API to retrieve column-names even when | ||
184 | a query returns no data. | ||
185 | </p> | ||
186 | |||
187 | <a name="pragma_encoding"></a> | ||
188 | <li><p><b>PRAGMA encoding; | ||
189 | <br>PRAGMA encoding = "UTF-8"; | ||
190 | <br>PRAGMA encoding = "UTF-16"; | ||
191 | <br>PRAGMA encoding = "UTF-16le"; | ||
192 | <br>PRAGMA encoding = "UTF-16be";</b></p> | ||
193 | <p>In first form, if the main database has already been | ||
194 | created, then this pragma returns the text encoding used by the | ||
195 | main database, one of "UTF-8", "UTF-16le" (little-endian UTF-16 | ||
196 | encoding) or "UTF-16be" (big-endian UTF-16 encoding). If the main | ||
197 | database has not already been created, then the value returned is the | ||
198 | text encoding that will be used to create the main database, if | ||
199 | it is created by this session.</p> | ||
200 | <p>The second and subsequent forms of this pragma are only useful if | ||
201 | the main database has not already been created. In this case the | ||
202 | pragma sets the encoding that the main database will be created with if | ||
203 | it is created by this session. The string "UTF-16" is interpreted | ||
204 | as "UTF-16 encoding using native machine byte-ordering". If the second | ||
205 | and subsequent forms are used after the database file has already | ||
206 | been created, they have no effect and are silently ignored.</p> | ||
207 | |||
208 | <p>Once an encoding has been set for a database, it cannot be changed.</p> | ||
209 | |||
210 | <p>Databases created by the ATTACH command always use the same encoding | ||
211 | as the main database.</p> | ||
212 | </li> | ||
213 | |||
214 | <a name="pragma_full_column_names"></a> | ||
215 | <li><p><b>PRAGMA full_column_names; | ||
216 | <br>PRAGMA full_column_names = </b><i>0 | 1</i><b>;</b></p> | ||
217 | <p>Query or change the full-column-names flag. This flag affects | ||
218 | the way SQLite names columns of data returned by SELECT statements | ||
219 | when the expression for the column is a table-column name or the | ||
220 | wildcard "*". Normally, such result columns are named | ||
221 | <table-name/alias><column-name> if the SELECT statement joins | ||
222 | two or | ||
223 | more tables together, or simply <column-name> if the SELECT | ||
224 | statement queries a single table. When the full-column-names flag | ||
225 | is set, such columns are always named <table-name/alias> | ||
226 | <column-name> regardless of whether or not a join is performed. | ||
227 | </p> | ||
228 | <p>If both the short-column-names and full-column-names are set, | ||
229 | then the behaviour associated with the full-column-names flag is | ||
230 | exhibited. | ||
231 | </p> | ||
232 | </li> | ||
233 | |||
234 | <a name="pragma_fullfsync"></a> | ||
235 | <li><p><b>PRAGMA fullfsync | ||
236 | <br>PRAGMA fullfsync = </b><i>0 | 1</i><b>;</b></p> | ||
237 | <p>Query or change the fullfsync flag. This flag affects | ||
238 | determines whether or not the F_FULLFSYNC syncing method is used | ||
239 | on systems that support it. The default value is off. As of this | ||
240 | writing (2006-02-10) only Mac OS X supports F_FULLFSYNC. | ||
241 | </p> | ||
242 | </li> | ||
243 | |||
244 | <a name="pragma_incremental_vacuum"></a> | ||
245 | <li><p><b>PRAGMA incremental_vacuum</b><i>(N)</i><b>;</b></p> | ||
246 | <p>The incremental_vacuum pragma causes up to <i>N</i> pages to | ||
247 | be removed from the freelist. The database file is truncated by | ||
248 | the same amount. The incremental_vacuum pragma has no effect if | ||
249 | the database is not in | ||
250 | <a href="#pragma_auto_vacuum">auto_vacuum==incremental</a> mode | ||
251 | or if there are no pages on the freelist. If there are fewer than | ||
252 | <i>N</i> pages on the freelist, then the entire freelist is cleared.</p> | ||
253 | |||
254 | <p>As of version 3.4.0 (the first version that supports | ||
255 | incremental_vacuum) this feature is still experimental. Possible | ||
256 | future changes include enhancing incremental vacuum to do | ||
257 | defragmentation and node repacking just as the full-blown | ||
258 | <a href="lang_vacuum.html">VACUUM</a> command does. And | ||
259 | incremental vacuum may be promoted from a pragma to a separate | ||
260 | SQL command, or perhaps some variation on the VACUUM command. | ||
261 | Programmers are cautioned to not become enamored with the | ||
262 | current syntax or functionality as it is likely to change.</p> | ||
263 | </li> | ||
264 | |||
265 | |||
266 | <a name="pragma_legacy_file_format"></a> | ||
267 | <li><p><b>PRAGMA legacy_file_format; | ||
268 | <br>PRAGMA legacy_file_format = <i>ON | OFF</i></b></p> | ||
269 | <p>This pragma sets or queries the value of the legacy_file_format | ||
270 | flag. When this flag is on, new SQLite databases are created in | ||
271 | a file format that is readable and writable by all versions of | ||
272 | SQLite going back to 3.0.0. When the flag is off, new databases | ||
273 | are created using the latest file format which might not be | ||
274 | readable or writable by older versions of SQLite.</p> | ||
275 | |||
276 | <p>This flag only affects newly created databases. It has no | ||
277 | effect on databases that already exist.</p> | ||
278 | </li> | ||
279 | |||
280 | <a name="pragma_locking_mode"></a> | ||
281 | <li><p><b>PRAGMA locking_mode; | ||
282 | <br>PRAGMA locking_mode = <i>NORMAL | EXCLUSIVE</i></b></p> | ||
283 | <p>This pragma sets or queries the database connection locking-mode. | ||
284 | The locking-mode is either NORMAL or EXCLUSIVE. | ||
285 | |||
286 | <p>In NORMAL locking-mode (the default), a database connection | ||
287 | unlocks the database file at the conclusion of each read or | ||
288 | write transaction. When the locking-mode is set to EXCLUSIVE, the | ||
289 | database connection never releases file-locks. The first time the | ||
290 | database is read in EXCLUSIVE mode, a shared lock is obtained and | ||
291 | held. The first time the database is written, an exclusive lock is | ||
292 | obtained and held.</p> | ||
293 | |||
294 | <p>Database locks obtained by a connection in EXCLUSIVE mode may be | ||
295 | released either by closing the database connection, or by setting the | ||
296 | locking-mode back to NORMAL using this pragma and then accessing the | ||
297 | database file (for read or write). Simply setting the locking-mode to | ||
298 | NORMAL is not enough - locks are not be released until the next time | ||
299 | the database file is accessed.</p> | ||
300 | |||
301 | <p>There are two reasons to set the locking-mode to EXCLUSIVE. One | ||
302 | is if the application actually wants to prevent other processes from | ||
303 | accessing the database file. The other is that a small number of | ||
304 | filesystem operations are saved by optimizations enabled in this | ||
305 | mode. This may be significant in embedded environments.</p> | ||
306 | |||
307 | <p>When the locking_mode pragma specifies a particular database, | ||
308 | for example:</p> | ||
309 | |||
310 | <blockquote> | ||
311 | PRAGMA <b>main.</b>locking_mode=EXCLUSIVE; | ||
312 | </blockquote> | ||
313 | |||
314 | <p>Then the locking mode applies only to the named database. If no | ||
315 | database name qualifier preceeds the "locking_mode" keyword then | ||
316 | the locking mode is applied to all databases, including any new | ||
317 | databases added by subsequent <a href="lang_attach.html">ATTACH</a> | ||
318 | commands.</p> | ||
319 | |||
320 | <p>The "temp" database (in which TEMP tables and indices are stored) | ||
321 | always uses exclusive locking mode. The locking mode of temp cannot | ||
322 | be changed. All other databases use the normal locking mode by default | ||
323 | and are affected by this pragma.</p> | ||
324 | </li> | ||
325 | |||
326 | <a name="pragma_page_size"></a> | ||
327 | <li><p><b>PRAGMA page_size; | ||
328 | <br>PRAGMA page_size = </b><i>bytes</i><b>;</b></p> | ||
329 | <p>Query or set the page-size of the database. The page-size | ||
330 | may only be set if the database has not yet been created. The page | ||
331 | size must be a power of two greater than or equal to 512 and less | ||
332 | than or equal to 8192. The upper limit may be modified by setting | ||
333 | the value of macro SQLITE_MAX_PAGE_SIZE during compilation. The | ||
334 | maximum upper bound is 32768. | ||
335 | </p> | ||
336 | </li> | ||
337 | |||
338 | <a name="pragma_max_page_count"></a> | ||
339 | <li><p><b>PRAGMA max_page_count; | ||
340 | <br>PRAGMA max_page_count = </b><i>N</i><b>;</b></p> | ||
341 | <p>Query or set the maximum number of pages in the database file. | ||
342 | Both forms of the pragma return the maximum page count. The second | ||
343 | form attempts to modify the maximum page count. The maximum page | ||
344 | count cannot be reduced below the current database size. | ||
345 | </p> | ||
346 | </li> | ||
347 | |||
348 | <a name="pragma_read_uncommitted"></a> | ||
349 | <li><p><b>PRAGMA read_uncommitted; | ||
350 | <br>PRAGMA read_uncommitted = </b><i>0 | 1</i><b>;</b></p> | ||
351 | <p>Query, set, or clear READ UNCOMMITTED isolation. The default isolation | ||
352 | level for SQLite is SERIALIZABLE. Any process or thread can select | ||
353 | READ UNCOMMITTED isolation, but SERIALIZABLE will still be used except | ||
354 | between connections that share a common page and schema cache. | ||
355 | Cache sharing is enabled using the | ||
356 | <a href="capi3ref.html#sqlite3_enable_shared_cache"> | ||
357 | sqlite3_enable_shared_cache()</a> API and is only available between | ||
358 | connections running the same thread. Cache sharing is off by default. | ||
359 | </p> | ||
360 | </li> | ||
361 | |||
362 | <a name="pragma_short_column_names"></a> | ||
363 | <li><p><b>PRAGMA short_column_names; | ||
364 | <br>PRAGMA short_column_names = </b><i>0 | 1</i><b>;</b></p> | ||
365 | <p>Query or change the short-column-names flag. This flag affects | ||
366 | the way SQLite names columns of data returned by SELECT statements | ||
367 | when the expression for the column is a table-column name or the | ||
368 | wildcard "*". Normally, such result columns are named | ||
369 | <table-name/alias>lt;column-name> if the SELECT statement | ||
370 | joins two or more tables together, or simply <column-name> if | ||
371 | the SELECT statement queries a single table. When the short-column-names | ||
372 | flag is set, such columns are always named <column-name> | ||
373 | regardless of whether or not a join is performed. | ||
374 | </p> | ||
375 | <p>If both the short-column-names and full-column-names are set, | ||
376 | then the behaviour associated with the full-column-names flag is | ||
377 | exhibited. | ||
378 | </p> | ||
379 | </li> | ||
380 | |||
381 | <a name="pragma_synchronous"></a> | ||
382 | <li><p><b>PRAGMA synchronous; | ||
383 | <br>PRAGMA synchronous = FULL; </b>(2)<b> | ||
384 | <br>PRAGMA synchronous = NORMAL; </b>(1)<b> | ||
385 | <br>PRAGMA synchronous = OFF; </b>(0)</p> | ||
386 | <p>Query or change the setting of the "synchronous" flag. | ||
387 | The first (query) form will return the setting as an | ||
388 | integer. When synchronous is FULL (2), the SQLite database engine will | ||
389 | pause at critical moments to make sure that data has actually been | ||
390 | written to the disk surface before continuing. This ensures that if | ||
391 | the operating system crashes or if there is a power failure, the database | ||
392 | will be uncorrupted after rebooting. FULL synchronous is very | ||
393 | safe, but it is also slow. | ||
394 | When synchronous is NORMAL, the SQLite database | ||
395 | engine will still pause at the most critical moments, but less often | ||
396 | than in FULL mode. There is a very small (though non-zero) chance that | ||
397 | a power failure at just the wrong time could corrupt the database in | ||
398 | NORMAL mode. But in practice, you are more likely to suffer | ||
399 | a catastrophic disk failure or some other unrecoverable hardware | ||
400 | fault. | ||
401 | With synchronous OFF (0), SQLite continues without pausing | ||
402 | as soon as it has handed data off to the operating system. | ||
403 | If the application running SQLite crashes, the data will be safe, but | ||
404 | the database might become corrupted if the operating system | ||
405 | crashes or the computer loses power before that data has been written | ||
406 | to the disk surface. On the other hand, some | ||
407 | operations are as much as 50 or more times faster with synchronous OFF. | ||
408 | </p> | ||
409 | <p>In SQLite version 2, the default value is NORMAL. For version 3, the | ||
410 | default was changed to FULL. | ||
411 | </p> | ||
412 | </li> | ||
413 | |||
414 | |||
415 | <a name="pragma_temp_store"></a> | ||
416 | <li><p><b>PRAGMA temp_store; | ||
417 | <br>PRAGMA temp_store = DEFAULT;</b> (0)<b> | ||
418 | <br>PRAGMA temp_store = FILE;</b> (1)<b> | ||
419 | <br>PRAGMA temp_store = MEMORY;</b> (2)</p> | ||
420 | <p>Query or change the setting of the "<b>temp_store</b>" parameter. | ||
421 | When temp_store is DEFAULT (0), the compile-time C preprocessor macro | ||
422 | TEMP_STORE is used to determine where temporary tables and indices | ||
423 | are stored. When | ||
424 | temp_store is MEMORY (2) temporary tables and indices are kept in memory. | ||
425 | When temp_store is FILE (1) temporary tables and indices are stored | ||
426 | in a file. The <a href="#pragma_temp_store_directory"> | ||
427 | temp_store_directory</a> pragma can be used to specify the directory | ||
428 | containing this file. | ||
429 | <b>FILE</b> is specified. When the temp_store setting is changed, | ||
430 | all existing temporary tables, indices, triggers, and views are | ||
431 | immediately deleted.</p> | ||
432 | |||
433 | <p>It is possible for the library compile-time C preprocessor symbol | ||
434 | TEMP_STORE to override this pragma setting. The following table summarizes | ||
435 | the interaction of the TEMP_STORE preprocessor macro and the | ||
436 | temp_store pragma:</p> | ||
437 | |||
438 | <blockquote> | ||
439 | <table cellpadding="2" border="1"> | ||
440 | <tr><th valign="bottom">TEMP_STORE</th> | ||
441 | <th valign="bottom">PRAGMA<br>temp_store</th> | ||
442 | <th>Storage used for<br>TEMP tables and indices</th></tr> | ||
443 | <tr><td align="center">0</td> | ||
444 | <td align="center"><em>any</em></td> | ||
445 | <td align="center">file</td></tr> | ||
446 | <tr><td align="center">1</td> | ||
447 | <td align="center">0</td> | ||
448 | <td align="center">file</td></tr> | ||
449 | <tr><td align="center">1</td> | ||
450 | <td align="center">1</td> | ||
451 | <td align="center">file</td></tr> | ||
452 | <tr><td align="center">1</td> | ||
453 | <td align="center">2</td> | ||
454 | <td align="center">memory</td></tr> | ||
455 | <tr><td align="center">2</td> | ||
456 | <td align="center">0</td> | ||
457 | <td align="center">memory</td></tr> | ||
458 | <tr><td align="center">2</td> | ||
459 | <td align="center">1</td> | ||
460 | <td align="center">file</td></tr> | ||
461 | <tr><td align="center">2</td> | ||
462 | <td align="center">2</td> | ||
463 | <td align="center">memory</td></tr> | ||
464 | <tr><td align="center">3</td> | ||
465 | <td align="center"><em>any</em></td> | ||
466 | <td align="center">memory</td></tr> | ||
467 | </table> | ||
468 | </blockquote> | ||
469 | </li> | ||
470 | <br> | ||
471 | |||
472 | <a name="pragma_temp_store_directory"></a> | ||
473 | <li><p><b>PRAGMA temp_store_directory; | ||
474 | <br>PRAGMA temp_store_directory = 'directory-name';</b></p> | ||
475 | <p>Query or change the setting of the "temp_store_directory" - the | ||
476 | directory where files used for storing temporary tables and indices | ||
477 | are kept. This setting lasts for the duration of the current connection | ||
478 | only and resets to its default value for each new connection opened. | ||
479 | |||
480 | <p>When the temp_store_directory setting is changed, all existing temporary | ||
481 | tables, indices, triggers, and viewers are immediately deleted. In | ||
482 | practice, temp_store_directory should be set immediately after the | ||
483 | database is opened. </p> | ||
484 | |||
485 | <p>The value <i>directory-name</i> should be enclosed in single quotes. | ||
486 | To revert the directory to the default, set the <i>directory-name</i> to | ||
487 | an empty string, e.g., <i>PRAGMA temp_store_directory = ''</i>. An | ||
488 | error is raised if <i>directory-name</i> is not found or is not | ||
489 | writable. </p> | ||
490 | |||
491 | <p>The default directory for temporary files depends on the OS. For | ||
492 | Unix/Linux/OSX, the default is the is the first writable directory found | ||
493 | in the list of: <b>/var/tmp, /usr/tmp, /tmp,</b> and <b> | ||
494 | <i>current-directory</i></b>. For Windows NT, the default | ||
495 | directory is determined by Windows, generally | ||
496 | <b>C:\Documents and Settings\<i>user-name</i>\Local Settings\Temp\</b>. | ||
497 | Temporary files created by SQLite are unlinked immediately after | ||
498 | opening, so that the operating system can automatically delete the | ||
499 | files when the SQLite process exits. Thus, temporary files are not | ||
500 | normally visible through <i>ls</i> or <i>dir</i> commands.</p> | ||
501 | |||
502 | </li> | ||
503 | </ul> | ||
504 | } | ||
505 | |||
506 | Section {Pragmas to query the database schema} schema | ||
507 | |||
508 | puts { | ||
509 | <ul> | ||
510 | <a name="pragma_database_list"></a> | ||
511 | <li><p><b>PRAGMA database_list;</b></p> | ||
512 | <p>For each open database, invoke the callback function once with | ||
513 | information about that database. Arguments include the index and | ||
514 | the name the database was attached with. The first row will be for | ||
515 | the main database. The second row will be for the database used to | ||
516 | store temporary tables.</p></li> | ||
517 | |||
518 | <a name="pragma_foreign_key_list"></a> | ||
519 | <li><p><b>PRAGMA foreign_key_list(</b><i>table-name</i><b>);</b></p> | ||
520 | <p>For each foreign key that references a column in the argument | ||
521 | table, invoke the callback function with information about that | ||
522 | foreign key. The callback function will be invoked once for each | ||
523 | column in each foreign key.</p></li> | ||
524 | |||
525 | <a name="pragma_freelist_count"></a> | ||
526 | <li><p><b>PRAGMA [database].freelist_count;</b></p> | ||
527 | <p>Return the number of unused pages in the database file. Running | ||
528 | a <a href="#pragma_incremental_vacuum">"PRAGMA incremental_vaccum(N);"</a> | ||
529 | command with a large value of N will shrink the database file by this | ||
530 | number of pages. </p></li> | ||
531 | |||
532 | <a name="pragma_index_info"></a> | ||
533 | <li><p><b>PRAGMA index_info(</b><i>index-name</i><b>);</b></p> | ||
534 | <p>For each column that the named index references, invoke the | ||
535 | callback function | ||
536 | once with information about that column, including the column name, | ||
537 | and the column number.</p></li> | ||
538 | |||
539 | <a name="pragma_index_list"></a> | ||
540 | <li><p><b>PRAGMA index_list(</b><i>table-name</i><b>);</b></p> | ||
541 | <p>For each index on the named table, invoke the callback function | ||
542 | once with information about that index. Arguments include the | ||
543 | index name and a flag to indicate whether or not the index must be | ||
544 | unique.</p></li> | ||
545 | |||
546 | <a name="pragma_table_info"></a> | ||
547 | <li><p><b>PRAGMA table_info(</b><i>table-name</i><b>);</b></p> | ||
548 | <p>For each column in the named table, invoke the callback function | ||
549 | once with information about that column, including the column name, | ||
550 | data type, whether or not the column can be NULL, and the default | ||
551 | value for the column.</p></li> | ||
552 | </ul> | ||
553 | } | ||
554 | |||
555 | Section {Pragmas to query/modify version values} version | ||
556 | |||
557 | puts { | ||
558 | |||
559 | <ul> | ||
560 | <a name="pragma_schema_version"></a> | ||
561 | <a name="pragma_user_version"></a> | ||
562 | <li><p><b>PRAGMA [database.]schema_version; | ||
563 | <br>PRAGMA [database.]schema_version = </b><i>integer </i><b>; | ||
564 | <br>PRAGMA [database.]user_version; | ||
565 | <br>PRAGMA [database.]user_version = </b><i>integer </i><b>;</b> | ||
566 | |||
567 | |||
568 | <p> The pragmas schema_version and user_version are used to set or get | ||
569 | the value of the schema-version and user-version, respectively. Both | ||
570 | the schema-version and the user-version are 32-bit signed integers | ||
571 | stored in the database header.</p> | ||
572 | |||
573 | <p> The schema-version is usually only manipulated internally by SQLite. | ||
574 | It is incremented by SQLite whenever the database schema is modified | ||
575 | (by creating or dropping a table or index). The schema version is | ||
576 | used by SQLite each time a query is executed to ensure that the | ||
577 | internal cache of the schema used when compiling the SQL query matches | ||
578 | the schema of the database against which the compiled query is actually | ||
579 | executed. Subverting this mechanism by using "PRAGMA schema_version" | ||
580 | to modify the schema-version is potentially dangerous and may lead | ||
581 | to program crashes or database corruption. Use with caution!</p> | ||
582 | |||
583 | <p> The user-version is not used internally by SQLite. It may be used by | ||
584 | applications for any purpose.</p> | ||
585 | </li> | ||
586 | </ul> | ||
587 | } | ||
588 | |||
589 | Section {Pragmas to debug the library} debug | ||
590 | |||
591 | puts { | ||
592 | <ul> | ||
593 | <a name="pragma_integrity_check"></a> | ||
594 | <li><p><b>PRAGMA integrity_check; | ||
595 | <br>PRAGMA integrity_check(</b><i>integer</i><b>)</b></p> | ||
596 | <p>The command does an integrity check of the entire database. It | ||
597 | looks for out-of-order records, missing pages, malformed records, and | ||
598 | corrupt indices. | ||
599 | If any problems are found, then strings are returned (as multiple | ||
600 | rows with a single column per row) which describe | ||
601 | the problems. At most <i>integer</i> errors will be reported | ||
602 | before the analysis quits. The default value for <i>integer</i> | ||
603 | is 100. If no errors are found, a single row with the value "ok" is | ||
604 | returned.</p></li> | ||
605 | |||
606 | <a name="pragma_parser_trace"></a> | ||
607 | <li><p><b>PRAGMA parser_trace = ON; </b>(1)<b> | ||
608 | <br>PRAGMA parser_trace = OFF;</b> (0)</p> | ||
609 | <p>Turn tracing of the SQL parser inside of the | ||
610 | SQLite library on and off. This is used for debugging. | ||
611 | This only works if the library is compiled without the NDEBUG macro. | ||
612 | </p></li> | ||
613 | |||
614 | <a name="pragma_vdbe_trace"></a> | ||
615 | <li><p><b>PRAGMA vdbe_trace = ON; </b>(1)<b> | ||
616 | <br>PRAGMA vdbe_trace = OFF;</b> (0)</p> | ||
617 | <p>Turn tracing of the virtual database engine inside of the | ||
618 | SQLite library on and off. This is used for debugging. See the | ||
619 | <a href="vdbe.html#trace">VDBE documentation</a> for more | ||
620 | information.</p></li> | ||
621 | |||
622 | <a name="pragma_vdbe_listing"></a> | ||
623 | <li><p><b>PRAGMA vdbe_listing = ON; </b>(1)<b> | ||
624 | <br>PRAGMA vdbe_listing = OFF;</b> (0)</p> | ||
625 | <p>Turn listings of virtual machine programs on and off. | ||
626 | With listing is on, the entire content of a program is printed | ||
627 | just prior to beginning execution. This is like automatically | ||
628 | executing an EXPLAIN prior to each statement. The statement | ||
629 | executes normally after the listing is printed. | ||
630 | This is used for debugging. See the | ||
631 | <a href="vdbe.html#trace">VDBE documentation</a> for more | ||
632 | information.</p></li> | ||
633 | </ul> | ||
634 | |||
635 | } | ||