System.Data.SQLite

Check-in [94e181cde0]
Login

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

Overview
Comment:Import the SQLite core library docs from upstream that correspond to version 3.12.0.
Downloads: Tarball | ZIP archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1: 94e181cde011a74ad8597d67ad93791c8485363b
User & Date: mistachkin 2016-03-29 20:40:56.203
Context
2016-03-30
21:02
Update the MSVCRT runtimes for VS 2015 in externals to 'Update 2', part 1. check-in: f586f38b68 user: mistachkin tags: trunk
2016-03-29
20:40
Import the SQLite core library docs from upstream that correspond to version 3.12.0. check-in: 94e181cde0 user: mistachkin tags: trunk
18:10
Update SQLite core library to the 3.12.0 release. check-in: 6b199ba3e1 user: mistachkin tags: trunk
Changes
Unified Diff Ignore Whitespace Patch
Changes to Doc/Extra/Core/pragma.html.
405
406
407
408
409
410
411
412

413
414
415
416
417
418
419
    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
    <a href="c3ref/pcache_methods2.html">Application Defined Page Cache</a>.
    The default page cache that is built into SQLite honors the request,
    however 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 pages.

    The default suggested cache size can be altered using the
    <a href="compile.html#default_cache_size">SQLITE_DEFAULT_CACHE_SIZE</a> compile-time options.
    The TEMP database has a default suggested cache size of 0 pages.</p>

    <p>If the argument N is positive then the suggested cache size is set 
    to N. If the argument N is negative, then the
    number of cache pages is adjusted to use approximately abs(N*1024) bytes







|
>







405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
    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
    <a href="c3ref/pcache_methods2.html">Application Defined Page Cache</a>.
    The default page cache that is built into SQLite honors the request,
    however 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, which means the cache size
    is limited to 2048000 bytes of memory.
    The default suggested cache size can be altered using the
    <a href="compile.html#default_cache_size">SQLITE_DEFAULT_CACHE_SIZE</a> compile-time options.
    The TEMP database has a default suggested cache size of 0 pages.</p>

    <p>If the argument N is positive then the suggested cache size is set 
    to N. If the argument N is negative, then the
    number of cache pages is adjusted to use approximately abs(N*1024) bytes
1145
1146
1147
1148
1149
1150
1151
1152
1153

1154

1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
<hr>
   <p><b>PRAGMA </b><i>schema.</i><b>page_size;
       <br>PRAGMA </b><i>schema.</i><b>page_size = </b><i>bytes</i><b>;</b></p>
    <p>Query or set the page size of the database. The page
    size must be a power of two between 512 and 65536 inclusive.
    </p>

    <p>When a new database is created, SQLite assigned a default page size
    based on information received from the xSectorSize and 

    xDeviceCharacteristics methods of the <a href="c3ref/io_methods.html">sqlite3_io_methods</a> object

    of the newly created database file.  The page_size pragma will only
    cause an immediate change in the
    page size if it is issued while the database is still empty, prior 
    to the first CREATE TABLE statement.  If the page_size pragma is
    used to specify a new page size just prior to
    running the <a href="lang_vacuum.html">VACUUM</a> command and if the database is not in
    <a href="wal.html">WAL journal mode</a> then <a href="lang_vacuum.html">VACUUM</a> will change the page
    size to the new value.</p>

    <p>If SQLite is compiled with the SQLITE_ENABLE_ATOMIC_WRITE option,
    then the default page size is chosen to be the largest page size
    less than or equal to SQLITE_MAX_DEFAULT_PAGE_SIZE for which atomic
    write is enabled according to the
    xDeviceCharacteristics method of the <a href="c3ref/io_methods.html">sqlite3_io_methods</a> object for
    the database file.  If the SQLITE_ENABLE_ATOMIC_WRITE option is
    disabled or if xDeviceCharacteristics reports no suitable atomic
    write page sizes, then the default page size is the larger of 
    SQLITE_DEFAULT_PAGE_SIZE
    and the sector size as reported by the xSectorSize method of the
    <a href="c3ref/io_methods.html">sqlite3_io_methods</a> object, but not more than 
    SQLITE_MAX_DEFAULT_PAGE_SIZE.  The normal configuration for SQLite
    running on workstations is for atomic write to be
    disabled, for the maximum page size to be set to 65536, 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 unix workstation implementations always reports a sector size
    of 512 bytes.  Hence, 
    the default page size chosen by SQLite on unix is usually 1024 bytes.
    On windows, the GetDiskFreeSpace() interface is used to obtain the
    actual device sector size and hence the default page size on windows
    will sometimes be greater than 1024.</p>
<a name="pragma_parser_trace"></a>
<hr>
    <p><b>PRAGMA parser_trace = </b><i>boolean</i><b>; </b></p>

    <p>If SQLite has been compiled with the <a href="compile.html#debug">SQLITE_DEBUG</a> compile-time
    option, then the parser_trace pragma can be used to turn on tracing
    for the SQL parser used internally by SQLite.







|
|
>
|
>
|
|







<
<
<
<
<
<
<
<
|
<
<
<
<
<
<
<
<
<
<
<
|
<







1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166








1167











1168

1169
1170
1171
1172
1173
1174
1175
<hr>
   <p><b>PRAGMA </b><i>schema.</i><b>page_size;
       <br>PRAGMA </b><i>schema.</i><b>page_size = </b><i>bytes</i><b>;</b></p>
    <p>Query or set the page size of the database. The page
    size must be a power of two between 512 and 65536 inclusive.
    </p>

    <p>When a new database is created, SQLite assigned a page size to
    the database based on platform and filesystem.  For many years,
    the default page size was almost always 1024 bytes, but beginning
    with SQLite <a href="releaselog/3_12_0.html">version 3.12.0</a> in 2016, the default page size increased
    to 4096.

    <p>The page_size pragma will only cause an immediate change in the
    page size if it is issued while the database is still empty, prior 
    to the first CREATE TABLE statement.  If the page_size pragma is
    used to specify a new page size just prior to
    running the <a href="lang_vacuum.html">VACUUM</a> command and if the database is not in
    <a href="wal.html">WAL journal mode</a> then <a href="lang_vacuum.html">VACUUM</a> will change the page
    size to the new value.</p>









    <p>The <a href="compile.html#default_page_size">SQLITE_DEFAULT_PAGE_SIZE</a> compile-time option can be used











    to change the default page size assigned to new databases.

<a name="pragma_parser_trace"></a>
<hr>
    <p><b>PRAGMA parser_trace = </b><i>boolean</i><b>; </b></p>

    <p>If SQLite has been compiled with the <a href="compile.html#debug">SQLITE_DEBUG</a> compile-time
    option, then the parser_trace pragma can be used to turn on tracing
    for the SQL parser used internally by SQLite.
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
    <dd>
    When synchronous is FULL (2), the SQLite database engine will
    use the xSync method of the <a href="vfs.html">VFS</a> to ensure that all content is safely
    written to the disk surface prior to continuing.
    This ensures that an operating system crash or power failure will
    not corrupt the database.
    FULL synchronous is very safe, but it is also slower.  FULL is the
    usual default setting when not in <a href="wal.html">WAL mode</a>.</dd>
    <dt><b>NORMAL</b> (1)</dt>
    <dd>
    When synchronous is NORMAL (1), the SQLite database
    engine will still sync at the most critical moments, but less often
    than in FULL mode.  There is a very small (though non-zero) chance that
    a power failure at just the wrong time could corrupt the database in
    NORMAL mode.  But in practice, you are more likely to suffer
    a catastrophic disk failure or some other unrecoverable hardware
    fault.  NORMAL is the default when in <a href="wal.html">WAL mode</a>.</dd>
    <dt><b>OFF</b> (0)</dt>
    <dd>
    With synchronous OFF (0), SQLite continues without syncing
    as soon as it has handed data off to the operating system.
    If the application running SQLite crashes, the data will be safe, but
    the database might become corrupted if the operating system
    crashes or the computer loses power before that data has been written







|








|







1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
    <dd>
    When synchronous is FULL (2), the SQLite database engine will
    use the xSync method of the <a href="vfs.html">VFS</a> to ensure that all content is safely
    written to the disk surface prior to continuing.
    This ensures that an operating system crash or power failure will
    not corrupt the database.
    FULL synchronous is very safe, but it is also slower.  FULL is the
    most commonly used synchronous setting when not in <a href="wal.html">WAL mode</a>.</dd>
    <dt><b>NORMAL</b> (1)</dt>
    <dd>
    When synchronous is NORMAL (1), the SQLite database
    engine will still sync at the most critical moments, but less often
    than in FULL mode.  There is a very small (though non-zero) chance that
    a power failure at just the wrong time could corrupt the database in
    NORMAL mode.  But in practice, you are more likely to suffer
    a catastrophic disk failure or some other unrecoverable hardware
    fault.  Many applications choose NORMAL when in <a href="wal.html">WAL mode</a>.</dd>
    <dt><b>OFF</b> (0)</dt>
    <dd>
    With synchronous OFF (0), SQLite continues without syncing
    as soon as it has handed data off to the operating system.
    If the application running SQLite crashes, the data will be safe, but
    the database might become corrupted if the operating system
    crashes or the computer loses power before that data has been written
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
    sync operation of the WAL file happens after each transaction commit.
    The extra WAL sync following each transaction help ensure that 
    transactions are durable across a power loss, but they do not aid
    in preserving consistency.
    If durability is not a concern, then synchronous=NORMAL is normally
    all one needs in WAL mode.</p>

    <p>The default setting is usually synchronous=FULL, 
    except in <a href="wal.html">WAL mode</a> when the default is synchronous=NORMAL.
    The <a href="compile.html#extra_durable">SQLITE_EXTRA_DURABLE</a> compile-time option changes the
    default to synchronous=EXTRA.</p>

    <p>See also the <a href="pragma.html#pragma_fullfsync">fullfsync</a> and <a href="pragma.html#pragma_checkpoint_fullfsync">checkpoint_fullfsync</a> pragmas.</p>
<a name="pragma_table_info"></a>
<hr>
    <p><b>PRAGMA </b><i>schema.</i><b>table_info(</b><i>table-name</i><b>);</b></p>







|
<







1417
1418
1419
1420
1421
1422
1423
1424

1425
1426
1427
1428
1429
1430
1431
    sync operation of the WAL file happens after each transaction commit.
    The extra WAL sync following each transaction help ensure that 
    transactions are durable across a power loss, but they do not aid
    in preserving consistency.
    If durability is not a concern, then synchronous=NORMAL is normally
    all one needs in WAL mode.</p>

    <p>The default setting is usually synchronous=FULL.

    The <a href="compile.html#extra_durable">SQLITE_EXTRA_DURABLE</a> compile-time option changes the
    default to synchronous=EXTRA.</p>

    <p>See also the <a href="pragma.html#pragma_fullfsync">fullfsync</a> and <a href="pragma.html#pragma_checkpoint_fullfsync">checkpoint_fullfsync</a> pragmas.</p>
<a name="pragma_table_info"></a>
<hr>
    <p><b>PRAGMA </b><i>schema.</i><b>table_info(</b><i>table-name</i><b>);</b></p>